Method and system for real-time blocking of content from an organization activity timeline

ABSTRACT

Methods and systems are provided for real-time blocking of content from an organization activity timeline of an organization. The content blocked can be, for example, activities, or contributions to those activities. The organization activity timeline is displayed within a user interface to show activities involving a particular external contact and one or more users of the organization. The disclosed methods and systems can be used to control which activities or contributions to activities are displayed in the organization activity timeline. One or more identifiers can be added to one or more blacklists. New activities are evaluated for inclusion in the organization activity timeline. Any new activity that includes an identifier (or contributions to that new activity) can be blocked so that it does not appear in the organization activity timeline.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a Divisional of U.S. application Ser. No.15/638,139, filed Jun. 29, 2017, the contents of which are herebyincorporated by reference.

TECHNICAL FIELD

Embodiments of the subject matter described herein relate generally tocloud-based computing. More particularly, embodiments of the subjectmatter relate to methods and systems for real-time content blocking andprivacy management within an activity timeline of an organization of acloud-based computing environment.

BACKGROUND

Today many enterprises now use cloud-based computing platforms thatallow services and data to be accessed over the Internet (or via othernetworks). Infrastructure providers of these cloud-based computingplatforms offer network-based processing systems that often supportmultiple enterprises (or tenants) using common computer hardware anddata storage. This “cloud” computing model allows applications to beprovided over a platform “as a service” supplied by the infrastructureprovider.

Multi-tenant cloud-based architectures have been developed to improvecollaboration, integration, and community-based cooperation betweencustomer tenants without compromising data security. Generally speaking,multi-tenancy may refer to a system where a single hardware and softwareplatform simultaneously supports multiple customers or tenants from acommon data storage element (also referred to as a “multi-tenant datastore”). The multi-tenant design provides a number of advantages overconventional server virtualization systems. First, the multi-tenantplatform operator can often make improvements to the platform based uponcollective information from the entire tenant community. Additionally,because all users in the multi-tenant environment execute applicationswithin a common processing space, it is relatively easy to grant or denyaccess to specific sets of data for any user within the multi-tenantplatform, thereby improving collaboration and integration betweenapplications and the data managed by the various applications. Themulti-tenant architecture therefore allows convenient and cost effectivesharing of similar application feature software between multiple sets ofusers.

A cloud-based computing environment can include a number of differentdata centers, and each data center can include a number of instances,where each instance can support many tenants (e.g., 10,000 tenants ormore). As such, large numbers of tenants can be grouped together intoand share an instance as tenants of that instance. Each tenant has itsown organization (or org). An organization or “org” is a uniqueidentifier (ID) that represents that tenant's data within an instance.Each identifier defines a virtual or logical space provided to anindividual tenant (e.g., a defined set of users) where all of thattenant's data and applications are stored within an instance so that itis separate from that of all other organizations that are part of thatinstance. An organization can be thought of as a logical container forone cohesive set of related data, metadata, configurations, settings andschemas that is separate from that of all other organizations. Eachorganization can be highly customized with respect to otherorganizations that are part of the same instance, and can include customfields, custom objects, workflows, data sharing rules, visual forcepages and apex coding because even though all tenants with an instanceshare the same database, the organization ID is stored in every table toensure that every row of data is linked back to the correct tenant andthe data from other tenants sharing the same instance cannot be mixedup.

Recently, a new activity timeline feature has been developed that allowsusers within an organization to view of an external contact's activitiesover time. This “organization activity timeline” can collect the mostrecent activities associated with a particular external contacttogether, and display them as a visual component in a user interfacethat arranges past activities and upcoming or future activitieschronologically across a dimension of time. By displaying a record ofactivities in the organization activity timeline, user's within theorganization can better understand information about another person orentity that is external to the organization.

Each activity that is displayed in the organization activity timelinehas at least one contributor who is a particular user within theorganization. Currently, contributions by any user within theorganization who contributes to an activity are displayed within theorganization activity timeline.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete understanding of the subject matter may be derived byreferring to the detailed description and claims when considered inconjunction with the following figures, wherein like reference numbersrefer to similar elements throughout the figures.

FIG. 1 is a schematic diagram of simplified representations ofcontributor activity timelines and an organization activity timeline inaccordance with the disclosed embodiments.

FIG. 2 is a block diagram that illustrates a stream fetch process usedto find a stream of recent activities for a particular user from anorganization activity timeline in accordance with the disclosedembodiments.

FIG. 3A is a block diagram that illustrates a management system forgenerating an organization activity timeline for an organization inaccordance with the disclosed embodiments.

FIG. 3B is a screenshot that shows an example of a user interfaceelement that can be used by any particular user who is a member of anorganization to define a user blacklist in accordance with the disclosedembodiments.

FIG. 3C is a screenshot that shows another example of a blacklistcontrol panel that can be used by an administrator of an organization todefine and manage various blacklists in accordance with the disclosedembodiments.

FIG. 4A is a flow chart that illustrates an exemplary method forretroactively scrubbing a user's past contributions from an organizationactivity timeline when the user adds a contact identifier to auser-level blacklist in accordance with the disclosed embodiments.

FIG. 4B is a schematic diagram of simplified representations of acontributor activity timeline and an organization activity timelinebefore and after retroactive scrubbing to remove some of the user'scontributions in accordance with the disclosed embodiments.

FIG. 4C is a screenshot of an organization activity timeline beforeretroactive scrubbing to remove some of the user's contributions inaccordance with the disclosed embodiments.

FIG. 4D is a screenshot of the organization activity timeline of FIG. 4Cafter retroactive scrubbing to remove some of the user's contributionsin accordance with the disclosed embodiments.

FIG. 5 is a flow chart that illustrates an exemplary method forreal-time content blocking based on a user-level blacklist to prevent auser's contributions from appearing in new activities that are beingevaluated for addition to an organization activity timeline inaccordance with the disclosed embodiments.

FIG. 6A is a flow chart that illustrates an exemplary method forretro-reactively adding a user's past contributions back into anorganization activity timeline when the user removes a contactidentifier from a user-level blacklist in accordance with the disclosedembodiments.

FIG. 6B is a schematic diagram of simplified representations of acontributor activity timeline and an organization activity timelinebefore and after retro-reactively adding some of the user's pastcontributions back into the organization activity timeline in accordancewith the disclosed embodiments.

FIG. 7A is a flow chart that illustrates an exemplary real-time activityevaluation method for determining whether new activities are allowed toappear in an organization activity timeline based on variousorganization-level blacklists in accordance with the disclosedembodiments.

FIG. 7B is a flow chart that illustrates an exemplary method forretroactively scrubbing a past activities from an organization activitytimeline when the administrator adds a contact identifier to anorganization-level blacklist in accordance with the disclosedembodiments.

FIG. 7C is a flow chart that illustrates an exemplary method forretroactively scrubbing a past activities from an organization activitytimeline when the administrator adds an external domain to anorganization-level external domain blacklist in accordance with thedisclosed embodiments.

FIG. 7D is a flow chart that illustrates an exemplary method forretroactively scrubbing a past activities from an organization activitytimeline when the administrator adds an internal domain to anorganization-level internal domain blacklist in accordance with thedisclosed embodiments.

FIG. 7E is a schematic diagram of simplified representations of anorganization activity timeline before an administrator adds a contactidentifier (Addr₀) to an organization-level blacklist and theorganization activity timeline after the administrator adds the contactidentifier (Addr₀) to an organization-level blacklist in accordance withthe disclosed embodiments.

FIG. 7F is a screenshot that shows an example of an organizationactivity timeline for notifications@github.com before an administratoradds the external domain github.com to an organization-level externaldomain blacklist in accordance with the disclosed embodiments.

FIG. 7G is a screenshot that shows an example of the organizationactivity timeline for notifications@github.com after an administratoradds the external domain github.com to the organization-level externaldomain blacklist in accordance with the disclosed embodiments.

FIG. 7H is a screenshot that shows an example of an organizationactivity timeline for eli@salesforceiq.com before an administrator addsthe internal domain salesforceiq.com to an organization-level internaldomain blacklist in accordance with the disclosed embodiments.

FIG. 7I is a screenshot that shows an example of the organizationactivity timeline for eli@salesforceiq.com after an administrator addsthe internal domain salesforceiq.com to the organization-level internaldomain blacklist in accordance with the disclosed embodiments.

FIG. 8 shows a block diagram of an example of an environment in which anon-demand database service can be used in accordance with someimplementations.

FIG. 9 shows a block diagram of example implementations of elements ofFIG. 8 and example interconnections between these elements according tosome implementations.

FIG. 10A shows a system diagram illustrating example architecturalcomponents of an on-demand database service environment according tosome implementations.

FIG. 10B shows a system diagram further illustrating examplearchitectural components of an on-demand database service environmentaccording to some implementations.

FIG. 11 illustrates a diagrammatic representation of a machine in theexemplary form of a computer system within which a set of instructions,for causing the machine to perform any one or more of the methodologiesdiscussed herein, may be executed.

DETAILED DESCRIPTION

The exemplary embodiments presented here relate to systems, methods,procedures, and technology for content blocking and privacy managementwithin an activity timeline of an organization of a cloud-basedcomputing environment. The described subject matter can be implementedin the context of any cloud-based computing environment including, forexample, a multi-tenant database system.

To help provide a degree of privacy, it would be desirable to provideusers within the organization with solutions that can allow them tocontrol which contributions and activities (e.g., events) appear withinthe organization's activity timeline. It would be desirable to provideadministrators of the organization with solutions that can allow them tocontrol or block which activities appear within the organization'sactivity timeline.

To address the issues discussed above, the disclosed embodiments canthus provide a retroactive, retro-reactive, real-time content blockingand privacy management systems and methods for an activity timeline. Todo so, various blacklists can be defined by a user or administrator ofan organization. Examples of these blacklists can include: a user-levelblacklist that can be defined by a user, an organization-level blacklistcan be defined by the administrator, an organization-level externaldomain blacklist that can be defined by the administrator, and anorganization-level internal domain blacklist that can be defined by theadministrator. The various blacklists can be maintained within adistributed database management system, and cached for fast read speedsso that thousands of incoming activities per second can be analyzed bythe system. User blacklists are shared by an organization and a user.Organization blacklists are shared by the organization. As activitiescome into the activity timeline, blacklist rules associated with eachblacklist are applied. All of this happens in near real-time via areal-time activity processing framework that will be described ingreater detail below. With each unique blacklist, the system ensuresindividual and organizational privacy, while also ensuring the qualityof any downstream analysis or reporting with the use or the internaldomain blacklist.

In one embodiment, a user-level blacklist can be defined by a user. Theuser can add a contact identifier (e.g., an email address) to auser-specific blacklist that will prevent the user's individualcontribution from showing up in organization-wide activity timelines forany given contact. In the base use case, meaning an activity (e.g., anemail or a calendar meeting) has a single contributor, the contributor'scontribution is removed and the activity simply does not appear in theorganization-wide activity timeline for the contact in question. In amore complex use case, an activity will have multiple contributors. Forexample, an email destined to multiple users. If the only one user addsthe contact identifier in question to his or her blacklist, the activitycorresponding to that email would still show up in the organization-wideactivity timeline for the contact.

For example, if an activity contains a contribution belonging to anemail in a user's blacklist, that contribution will not make it to theorganization-wide activity timeline. For instance, if a user, named Bob,of an organization adds the email alice@somecompany.com to hisblacklist, when other users of Bob's organization view the activitytimeline for Alice's contact, any emails where Bob was the solecontributor to an email to alice@somecompany.com will not show up forother users in the organization. If there are more contributors to theemail, Bob's contribution will be removed, while maintaining thecontributions from other users. So, if other users do not havealice@somecompany.com in their respective blacklists, activitiescorresponding to that email address will be displayed for other users inthe organization.

Additionally, when a user adds any given contact identifier (e.g., anemail address) to his or her blacklist, activities corresponding to thatcontact identifier will be retroactively “scrubbed” from the activitytimeline. All of the scrubbing operations happen in real time. Theprivacy management systems and methods are retroactive, in thatscrubbing operations can be performed to remove past activities from theactivity timeline.

The user can also remove a contact identifier from a user-level (oruser-specific) blacklist, and the scrubbing operation can be performedin reverse. For example, if the user removes the contact identifier fromhis or her blacklist, the contribution (or activity) will beretro-reactively added back to the organization-wide activity timeline.As such, the privacy management systems and methods are retro-reactive,in that the user's blacklist operations can be performed in reverse overpast activities.

In another embodiment, an organization-level blacklist can be defined byan administrator of an organization. When an administrator adds acontact identifier to the organization-level blacklist, the system canperform a similar type of activity scrubbing, but rather than removingany user's contributions, any activities that include a contributionbelonging to a contact identifier (e.g., an email address) that isincluded in the organization-level blacklist will be hard-deleted withno possibility of it coming back. In addition, if an activity contains acontribution belonging to a contact identifier (e.g., an email address)that is included in the organization-level blacklist, that activity willnot make it to the organization-wide activity timeline, and can not beadded back into the organization-wide activity timeline.

In another embodiment, an organization-level external domain blacklistcan be defined by an administrator. When an administrator adds anexternal domain to the organization-level blacklist, the system canperform a similar type of activity scrubbing, but rather than removingany user's contributions, any activities that include one or morecontributions belonging to an external domain (that is included in theorganization external domain blacklist) will be hard-deleted with nopossibility of coming back. In addition, if an activity contains one ormore contributions belonging to an external domain (that is included inthe organization external domain blacklist), that activity will not makeit to the organization-wide activity timeline, and can not be added backinto the organization-wide activity timeline.

In another embodiment, an organization-level internal domain blacklistcan be defined by an administrator. The administrator can specify thedomain of the organization, along with any alias domains theorganization may use, to define the organization-level internal domainblacklist. When an administrator adds an internal domain to theorganization-level internal blacklist, the system can perform a pastactivity scrubbing operation where past activities are evaluated. Anyactivities that has all of its contributions belonging to the internaldomain (that is included in the organization internal domain blacklist)will be hard-deleted with no possibility of coming back. In other words,for a particular past activity, if it is determined that allcontributions to that past activity belong to a contributor with theinternal domain in the organization-level internal domain blacklist,then that past activity will be removed from the organization-wideactivity timeline, with no possibility of it coming back. When a newactivity is evaluated for inclusion in the organization-wide activitytimeline, and all of an activity's contributions belong to an internaldomain in the organization-level internal domain blacklist, then thatactivity will not make it to the organization-wide activity timeline,with no possibility of it coming back. In other words, if allcontributions to the activity belong to an internal domain (that isincluded in the organization internal domain blacklist), that activitywill not make it to the organization-wide activity timeline, and can notbe added back into the organization-wide activity timeline. Thisinternal domain blacklist is useful for enhancing the quality of dataused for downstream reporting because any downstream reporting systems,which would depend on the activity timeline for data, are not cloudedwith noise (e.g., internal emails with nothing to do with customercommunication).

Prior to describing exemplary embodiments with reference to FIGS. 1-11certain terminology will be defined.

Multi-Tenant Database System

As used herein, the term “multi-tenant database system” may refer tothose systems in which various elements of hardware and software of thedatabase system may be shared by one or more tenants. For example, agiven application server may simultaneously process requests for a greatnumber of tenants, and a given database table may store rows for apotentially much greater number of tenants. In a multitenantarchitecture a number of tenants share IT resources such as databaseservers, application servers, and infrastructure required to runapplications, resulting in an environment where resources are managedcentrally.

Data Center and Instances

A cloud-based computing environment can include a number of differentdata centers. Each data center can include a number of instances. Eachinstance can support many (e.g., 10,0000) tenants, where each tenant hastheir own organization (or org).

An instance (also known as a point of deployment (POD)) is a cluster ofsoftware and hardware represented as a single logical server that hostsmultiple organization's data and runs their applications. An instancecan be a self-contained unit that contains all that is required to runan instance including the application server, database server, databaseitself, search and file system. Large numbers of tenants, for example,10,000, can be grouped together into and share an instance as tenants ofthat instance. A platform as a service (PaaS), such as the Force.complatform, can run on multiple instances, but data for any singleorganization is always stored on a single instance where their dataresides. Each tenant is allocated to one and only one instance (or POD)and that is where their data resides. As such, an instance may refer toa single logical server that multiple organizations live on as tenants.An instance can be identified in a URL by a region and a server number.For example, if it is assumed that there are currently 21 instances inNorth America, in the URL na8.salesforce.com, nab can refer toparticular server, where na may refer to the general location of theserver (North America) and 8 may refer to the serverID within thatgeneral location (server 8 of 21 in North America).

Organization

An organization or “org” is a unique identifier (ID) that representsthat tenant's data within an instance. Each identifier defines a virtualor logical space provided to an individual tenant (e.g., a deployment ofSalesforce with a defined set of licensed users) where all of thattenant's data and applications are stored within an instance so that itis separate from that of all other organizations that are part of thatinstance. As such, each organization can be identified by its own uniqueID that allows that organization's data to be separated from data ofother organizations. The ID serves as an access key and a securitybarrier for an individual tenant's data in the system. An organizationcan be thought of as a logical container for one cohesive set of relateddata, metadata, configurations, settings and schemas. An organizationincludes all of a tenant's data and applications, and is separate fromthat of all other organizations. Each organization can be highlycustomized with respect to other organizations that are part of the sameinstance, and can include custom fields, custom objects, workflows, datasharing rules, visual force pages and apex coding because even thoughall tenants with an instance share the same database, the organizationID is stored in every table to ensure that every row of data is linkedback to the correct tenant and the data from other tenants sharing thesame instance cannot be mixed up.

Records and Objects

As used herein, the term “record” can refer to a particular occurrenceor instance of a data object that is created by a user or administratorof a database service and stored in a database system, for example,about a particular (actual or potential) business relationship orproject. An object can refer to a structure used to store data andassociated metadata along with a globally unique identifier (called anidentity field) that allows for retrieval of the object. In oneembodiment implementing a multi-tenant database, all of the records forthe tenants have an identifier stored in a common table. Each objectcomprises a number of fields. A record has data fields that are definedby the structure of the object (e.g. fields of certain data types andpurposes). An object is analogous to a database table, fields of anobject are analogous to columns of the database table, and a record isanalogous to a row in a database table. Data is stored as records of theobject, which correspond to rows in a database. The terms “object” and“entity” are used interchangeably herein. Objects not only providestructure for storing data, but can also power the interface elementsthat allow users to interact with the data, such as tabs, the layout offields on a page, and lists of related records. Objects can also havebuilt-in support for features such as access management, validation,formulas, triggers, labels, notes and attachments, a track field historyfeature, security features, etc. Attributes of an object are describedwith metadata, making it easy to create and modify records eitherthrough a visual interface or programmatically.

A record can also have custom fields defined by a user. A field can beanother record or include links thereto, thereby providing aparent-child relationship between the records. Customizations caninclude custom objects and fields, Apex Code, Visualforce, Workflow,etc.

Examples of objects include standard objects, custom objects, andexternal objects. A standard object can have a pre-defined datastructure that is defined or specified by a database service or cloudcomputing platform. A standard object can be thought of as a defaultobject. For example, in one embodiment, a standard object includes oneor more pre-defined fields that are common for each organization thatutilizes the cloud computing platform or database system or service.

A few non-limiting examples of standard objects can include salesobjects (e.g., accounts, contacts, opportunities, leads, campaigns, andother related objects); task and event objects (e.g., tasks and eventsand their related objects); support objects (e.g., cases and solutionsand their related objects); salesforce knowledge objects (e.g., view andvote statistics, article versions, and other related objects); document,note, attachment objects and their related objects; user, sharing, andpermission objects (e.g., users, profiles, and roles); profile andpermission objects (e.g., users, profiles, permission sets, and relatedpermission objects); record type objects (e.g., record types andbusiness processes and their related objects); product and scheduleobjects (e.g., opportunities, products, and schedules); sharing and teamselling objects (e.g., account teams, opportunity teams, and sharingobjects); customizable forecasting objects (e.g., includes forecasts andrelated objects); forecasts objects (e.g., includes objects forcollaborative forecasts); territory management (e.g., territories andrelated objects associated with territory management); process objects(e.g., approval processes and related objects); content objects (e.g.,content and libraries and their related objects); chatter feed objects(e.g., objects related to feeds); badge and reward objects; feedback andperformance cycle objects, etc. For example, a record can be for abusiness partner or potential business partner (e.g. a client, vendor,distributor, etc.) of the user, and can include an entire company,subsidiaries, or contacts at the company. As another example, a recordcan be a project that the user is working on, such as an opportunity(e.g. a possible sale) with an existing partner, or a project that theuser is trying working on.

By contrast, a custom object can have a data structure that is defined,at least in part, by an organization or by a user/subscriber/admin of anorganization. For example, a custom object can be an object that iscustom defined by a user/subscriber/administrator of an organization,and includes one or more custom fields defined by the user or theparticular organization for that custom object. Custom objects arecustom database tables that allow an organization to store informationunique to their organization. Custom objects can extend thefunctionality that standard objects provide.

In one embodiment, an object can be a relationship management entityhaving a record type defined within platform that includes a customerrelationship management (CRM) database system for managing a company'srelationships and interactions with their customers and potentialcustomers. Examples of CRM entities can include, but are not limited to,an account, a case, an opportunity, a lead, a project, a contact, anorder, a pricebook, a product, a solution, a report, a forecast, a user,etc. For instance, an opportunity can correspond to a sales prospect,marketing project, or other business related activity with respect towhich a user desires to collaborate with others.

External objects are objects that an organization creates that map todata stored outside the organization. External objects are, like customobjects, but external object record data is stored outside theorganization. For example, data that's stored on premises in anenterprise resource planning (ERP) system can be accessed as externalobjects in real time via web service callouts, instead of copying thedata into the organization.

Organization Activity Timeline

Users who are part of the organization contribute activities to thesystem. These users are also referred to as contributors herein. Theseactivities can be displayed in an organization activity timeline view.As used herein, the term “organization activity timeline” may refer toan organization-wide view of an external contact's activities over time.An external contact is another person or entity that is external to theorganization. The most recent activities associated with a particularexternal contact can be collected together, and displayed in anorganization activity timeline. For example, a query can be ran based ona contact identifier associated with a particular external contact togenerate a visual representation that shows the most recent activitiesassociated with that particular external contact. The organizationactivity timeline of an organization can include a record of activitieseach having at least one contributor, where a contributor is aparticular user within the organization. The organization activitytimeline can be presented as a visual component in a user interface thatarranges activities chronologically across a dimension of time. Theactivities displayed in the organization activity timeline can includepast activities and upcoming or future activities.

Activity

As used herein, the term “activity” can refer to a recording of acommunication. Examples of such communications can include emails,calendar meetings, phone calls, tasks, changed or deleted meetings,notes, changes to an internal representation of an external person, aninternal representation of the need or change of that need to follow-upwith an external person, and any others that correspond to acommunication between one or more users, and usually involving externalpeople who are not users in the organization. An activity can relate toa particular object, like an opportunity or task, and can include anyevents that happens within an organization related to a particularexternal contact. As such, in some cases, the terms “activity” and“event” can be used interchangeably depending on the context. Activitiesrelated to objects can be displayed in an organization activity timelineview. For instance, a few non-limiting examples of activities that canbe displayed can include activities related to an opportunity, lead,account, contact, and any custom objects on which a user enableactivities. The activity timeline can display all activities in acontinuum from future to past. For example, in one implementation, fromtop to bottom, the timeline displays activities in chronological orderto today with undated tasks at the top and overdue tasks at the bottom.

Actions

In the activity timeline, a user can define a set of actions that aredisplayed. The set of actions displayed can be driven off of metadata,specifically page layouts. Actions are configurable for each data objecttype. For example, various actions can be specified for an opportunityobject and any activities related to those various actions for thatopportunity object will appear in the activity timeline. For instance,actions such as Log a Call, New Task, New Event, and Email can bedisplayed on the activity timeline.

Contribution

As used herein, the term “contribution” may refer to input by a user ofan organization to an activity. For example, if a user in theorganization sends an email to an external contact, that email has asingle user contribution. If the user sends the email with another usercc-ed, that email has two user's contributions. For calendar meetings,if two users from the organization are invited as attendees, then themeeting has two contributions. Users can contribute in a variety ofways, one of which is to connect external data sources like their emailand calendar accounts, but contributions are not limited to connectionsto external data source since any recording of communication can beentered manually if there is not a direct link to the source of data tocreate activities.

Contact Identifier

As used herein, the term “contact identifier” may refer to anyidentifier associated with a particular contact that can be used toidentify that particular contact. In many cases a contact identifier isan email address of that particular contact, but other examples caninclude a telephone number of the contact, a social media handle of thecontact, or any other information that can be used to uniquely identifya particular contact.

FIG. 1 is a schematic diagram of simplified representations ofcontributor activity timelines 120, 130 and an organization activitytimeline 140 in accordance with the disclosed embodiments.

The organization activity timeline 140 provides an organization-wideview of an external contact's activities over time. This organizationactivity timeline 140 can collect the most recent activities 102, 104,108, 110, 112, 114, 116, 118 associated with a particular externalcontact together, and display them as a visual component in a userinterface that arranges past activities and upcoming or futureactivities chronologically across a dimension of time.

The organization activity timeline 140 is generated based on activitiesfrom contributor activity timelines 120, 130 that relate to the externalcontact. In this simplified example, only two contributor activitytimelines 120, 130 are shown, but it should be appreciated that anorganization would typically include many individual users (e.g., 10,000or more in some organizations) who could be contributors, and that theactivities of each user (or a subset of the users) can be displayedwithin the organization activity timeline 140. The contributor activitytimelines 120, 130 are not displayed, but the activities that make upeach contributor activity timeline 120, 130 can be used to define theactivities that make up the organization activity timeline 140 that isdisplayed to users who are part of the organization. This simplifiedrepresentation of contributor activity timeline 120 includes activities102, 104, 108 that relate to the external contact, and the simplifiedrepresentation of contributor activity timeline 130 includes activities110, 112, 114, 116, 118 that relate to the external contact. Theactivities from each of the contributor activity timelines 120, 130 canthen be displayed within the organization activity timeline 140 so thateach user who is a member of the organization has a view of allactivities 102, 104, 108, 110, 112, 114, 116, 118 that relate to theexternal contact. By displaying a record of activities in theorganization activity timeline, user's within the organization canbetter understand information about another person or entity that isexternal to the organization.

FIG. 2 is a block diagram that illustrates a stream fetch processingsystem 200 used to find a stream of recent activities for a particularuser (Addr₀) from the organization activity timeline of FIG. 1 inaccordance with the disclosed embodiments. The system 200 includes anenterprise search engine 210 and a distributed database managementsystem 220.

In one embodiment, the enterprise search engine 210 can be implementedusing ElasticSearch. Elasticsearch is a flexible and powerful opensource, distributed, real-time search and analytics engine based onLucene. Elasticsearch is developed in Java and is released as opensource under the terms of the Apache License. It provides a distributed,multitenant-capable full-text search engine with an HTTP web interfaceand schema-free JSON documents. It provides scalable search, has nearreal-time search, and supports multitenancy. Elastiscsearch was builtfrom the ground up for use in distributed environments where reliabilityand scalability are important. Elasticsearch enables comprehensivesearches well beyond simple full-text search, and can be used to searchall kinds of documents. Elasticsearch includes a robust set of APIs andquery DSLs, as well as clients that support a variety of programminglanguages.

In one embodiment, the distributed database management system 220 can beimplemented using Apache Cassandra database management system. ApacheCassandra is a free and open-source distributed NoSQL databasemanagement system designed to handle large amounts of data across manycommodity servers, providing high availability with no single point offailure. Cassandra offers robust support for clusters spanning multipledatacenters, with asynchronous masterless replication allowing lowlatency operations for all clients.

For example, the enterprise search engine 210 can be used to search thevarious activities 102, 104, 108, 110, 112, 114, 116, 118 from theorganization activity timeline 140 to find and fetch a subset of partialobjects associated with that contact identifier (Addr₀) from theorganization activity timeline 140. The partial objects can then be usedto fetch a stream of full activity objects 102, 112,108, 116 associatedwith that contact identifier (Addr₀) from the distributed databasemanagement system 220.

For example, in one embodiment, an Elasticsearch engine 210 can bequeried (e.g., by date ranges) to obtain indexed events that containsparse information about activities and their contributions (e.g., highlevel details of an email). The distributed database management system220 can be partitioned, for example, with a composite primary keycomposed of an organization identifier (orgId) and a user identifier(userId) such that all of an organization's data is on a singlepartition to optimize read performance. Based on the indexed events, thedistributed database management system 220 can be queried to populateactivity metadata for activities (e.g., bodies of an email).

The set of full activity objects (or activities) from the distributeddatabase management system 220 can then be sent as a stream of recentactivities 102, 112,108, 116 to the client (not shown). The set of fullactivity objects (or activities) make up an activity timeline 150 forthat contact identifier (Addr₀).

FIG. 3A is a block diagram that illustrates a management system 300 forgenerating an organization activity timeline for an organization inaccordance with the disclosed embodiments. As will be explained ingreater detail below with reference to FIGS. 3B-7I, the managementsystem 300 can provide features for real-time content blocking andprivacy management within an organization activity timeline, and/orfeatures for retroactive removal of content from the organizationactivity timeline.

The system 300 includes a distributed database management system (DDMS)320, data storage 322, and an organization activity timeline generator328. The DDMS stores a number of different blacklists includinguser-level blacklists for specific contacts specified by users of theorganization, organization-level blacklists for specific contactsspecified by the administrator, organization-level external domainblacklists for specific external domains specified by the administrator,and organization-level internal domain blacklists for specific internaldomains specified by the administrator. The data storage 322 storesvarious activities that may appear in the organization activity timeline(depending on application of blacklists).

The organization activity timeline generator 328 includes a real-timeactivity evaluator 330 and a past activity scrubber 332. The real-timeactivity evaluator 330 and past activity scrubber 332 apply the variousblacklists to restrict activities, or contributions to certainactivities, so that they do not appear on the organization activitytimeline.

The real-time activity evaluator 330 is an ingestion-time filter that isdefined or determined by the blacklists stored at the DDMS 320. Thereal-time activity evaluator 330 crawls the user's datasources (e.g.,their email and calendar accounts) to find new activities (e.g., emailsand calendar) to evaluate. After finding the new activities to evaluatefrom the user's datasources, and before indexing at the enterprisesearch engine 210 and saving in distributed database management system220, the real-time activity evaluator 330 can perform real-timeevaluation of new activities to determine whether any user'scontributions to those activities, or the activities in their entirety,should be blocked from appearing in the organization activity timeline.As will be described in greater detail below with reference to FIGS. 5and 7A-7D, whether the real-time activity evaluator 330 blocks theentire activity or just certain user's contributions to the activitydepends on how many contributors from the organization there are to theactivity and the particular blacklist that is applied.

On the other hand, the past activity scrubber 332 can perform scrubbingof past activities or scrubbing of specific user's contributions tothose activities. Again, this depends on which blacklists are applied,and how many contributors from the organization there are to eachactivity. For example, in one embodiment, a multi-year query can beperformed via ElasticSearch enterprise search engine 210 to findactivities. A real-time activity processing framework (Storm) can thenquery one week at a time, and the past activity scrubber 332 can performa scrub operation for a user-level blacklist to remove contributions toactivities (or entire activities) so that they will not appear in theorganization activity timeline, or can perform a hard-delete operationfor various organization-level blacklists to hard-delete of certainactivities so that they will not appear in the organization activitytimeline. For example, when a user is the sole contributor to anactivity and has blocked a specific contact via a user-level blacklist,the past activity scrubber 332 can remove the entire activity so that itwill not appear in the organization activity timeline. By contrast, whenthere are other contributors to a certain activity, the past activityscrubber 332 can simply remove the certain user's contributions to thatactivity so that the user's contributions do not appear in theorganization activity timeline. When organization-level blacklists areapplied (and certain constraints are met), the past activity scrubber332 may completely remove or scrub any past activity so that the pastactivity does not appear in the organization activity timeline.

FIG. 3B is a screenshot that shows an example of a user interfaceelement 340 that can be used by any particular user who is a member ofan organization to define user-level blacklists in accordance with thedisclosed embodiments. To do so, the user can enter a contactidentifier, such as an email address in the text field 342, and thenselect the add button 344. The will cause the contact identifier toappear in region 346 along with the date the contact identifier wasadded.

FIG. 3C is a screenshot that shows another example of a blacklistcontrol panel 350 that can be used by an administrator of anorganization to define and manage various blacklists in accordance withthe disclosed embodiments. FIG. 3C shows the blacklist control panel 350after the administrator has defined various organization-levelblacklists 362, 364, 366.

The administrator of the organization can create organization-levelblacklists for specific contacts by specifying a contact identifier suchas an email address. In this particular example, an administrator hasdefined an organization-level blacklist 362 that includes a contactidentifier emadill@lkglobal.com. To define the organization-levelblacklist, the administrator can enter the contact identifier in thetext field 352, and then select the add button 354. The will cause thecontact identifier to appear in region 356 along with the date thecontact identifier was added.

In addition, the administrator can also use the blacklist control panel350 to create or define organization-level external domain blacklistsfor specific external domains specified by the administrator, andorganization-level internal domain blacklists for specific internaldomains specified by the administrator. To define organization-levelexternal domain blacklists for specific external domains, theadministrator can enter a contact identifier, such as a domain in thetext field 352, select a type of domain via radio button 358, and thenselect the add button 354. The will cause the contact identifier toappear in region 356 along with a type, a domain type, a last modifieddate that indicates when the contact identifier was added, and a lastmodified by field that indicates who created or modified the entry. Inthis example, the administrator has added two external domains,yahoo.com and happy.com, as the organization-level external domainblacklists. Similarly, to define organization-level internal domainblacklists for specific internal domains, the administrator can enter acontact identifier, such as a domain in the text field 352, select atype of domain via radio button 360, and then select the add button 354.The will cause the contact identifier to appear in region 356 along witha type, a domain type, a last modified date that indicates when thecontact identifier was added, and a last modified by field thatindicates who created or modified the entry. In this example, theadministrator has added one internal domain, salesforce.com, as anorganization-level internal domain blacklist.

FIG. 4A is a flow chart that illustrates an exemplary method 400 forretroactively scrubbing a user's past contributions from an organizationactivity timeline when the user adds a contact identifier to auser-level blacklist in accordance with the disclosed embodiments. As apreliminary matter, it should be understood that steps of the method 400are not necessarily limiting, and that steps can be added, omitted,and/or performed simultaneously without departing from the scope of theappended claims. It should be appreciated that the method 400 mayinclude any number of additional or alternative tasks, that the tasksshown in FIG. 4A need not be performed in the illustrated order, andthat the method 400 may be incorporated into a more comprehensiveprocedure or process having additional functionality not described indetail herein. Moreover, one or more of the tasks shown in FIG. 4A couldpotentially be omitted from an embodiment of the method 400 as long asthe intended overall functionality remains intact. It should also beunderstood that the illustrated method 400 can be stopped at any time.The method 400 is computer-implemented in that various tasks or stepsthat are performed in connection with the method 400 may be performed bysoftware, hardware, firmware, or any combination thereof. Forillustrative purposes, the following description of the method 400 mayrefer to elements mentioned above in connection with FIGS. 2 and 3A. Incertain embodiments, some or all steps of this process, and/orsubstantially equivalent steps, are performed by execution ofprocessor-readable instructions stored or included on aprocessor-readable medium.

At some point prior to the start of the method 400, the user adds one ormore contact identifiers, such as email addresses, to a user-levelblacklist. This is represented in FIG. 4A by block 410. For sake ofsimplicity the following description will focus on a single contactidentifier for a single contact being added to the user-level blacklist,but it should be appreciated that the user could add any number ofcontact identifiers for any number of contacts to the user-levelblacklist. The method 400 begins at 420, when the elastic search engine210 performs a search to find all activities in the organizationactivity timeline that include a contact identifier from the user's ofuser-level blacklist. The organization activity timeline the particularcontacts activities with all users of the organization, and includes anycontributions by all users of the organization. Step 420 can betriggered, for example, each time a contact identifier is added theuser's of user-level blacklist, at which point the system can searchactivities in the organization activity timeline that include thatcontact identifier.

At 430, the past activity scrubber 332 can then scrub (e.g., remove) theuser's prior contributions to each activity that is associated with thecontact identifier(s) so that any prior contributions by that user tothose activities do not appear in the organization activity timeline toother users of the organization.

For example, when the past activity scrubber 332 determines that thisuser is the sole contributor within the organization to an activity, thepast activity scrubber 332 can remove the entire activity so that itdoes not appear in the organization activity timeline to other users ofthe organization.

By contrast, when the past activity scrubber 332 determines that thisuser is not the sole contributor within the organization to an activity,then the past activity scrubber 332 can remove the user'scontribution(s) to that activity so that any contributions by the userto the activity do not appear in the organization activity timeline toother users of the organization. However, contributions of other usersof the organization to that activity are allowed to remain in theorganization activity timeline unless the other users also have thatcontact identifier in their user-level blacklist, in which case thecontributions of those users would also be removed from the activitytimeline.

FIG. 4B is a schematic diagram of simplified representations of acontributor activity timeline (User0) and an organization activitytimeline before and after retroactive scrubbing to remove some of theuser's contributions in accordance with the disclosed embodiments. Here,it assumed that a user (User0) of the organization has added a contactidentifier to their user-level blacklist, and that User0 has contributedto activities 442, 444, 448 are associated with that contact identifier.With respect to activities 442, 444, User0 is the sole contributorwithin the organization to those activities (e.g., emails between User0and the contact associated with the contact identifier), whereas thereare other contributors within the organization to activity 448. Asshown, prior to adding the contact identifier to User0's user-levelblacklist, activities 442, 444, 448 all appear in the organizationactivity timeline. By contrast, after adding the contact identifier toUser0's user-level blacklist, the past activity scrubber 332 can scrubsUser0's prior contributions to each activity 442, 444, 448 that isassociated with the contact identifier. Activities 442, 444 no longerappear in the organization activity timeline because User0 was the solecontributor within the organization to those activities, while activity448 still appears in the organization activity timeline because User0was not the sole contributor within the organization to activity 448.However, User0's contributions to activity 448 have been removed so thatthey do not appear in the organization activity timeline to other usersof the organization. As such, User0's prior contributions to eachactivity that is associated with the contact identifier no longer appearin the organization activity timeline to other users of theorganization. Contributions of other users of the organization toactivity 448 remain in the organization activity timeline (unless theother users also have the contact identifier in their user-levelblacklist, in which case the contributions of those users would also beremoved from the activity timeline).

FIG. 4C is a screenshot of an organization activity timeline beforeretroactive scrubbing to remove some of the user's contributions, andFIG. 4D is a screenshot of the organization activity timeline of FIG. 4Cafter retroactive scrubbing to remove some of the user's contributions.Here, it assumed that a user (Eli Hickox) of the organization has addeda contact identifier for Erin Madill to his user-level blacklist, andthat Eli Hickox has contributed to all of the past activities (emails inthis example) shown in FIG. 4C that include at least Eli Hickox and ErinMadill. With respect to all of the activities except activity 460, EliHickox is the sole contributor within the organization to thoseactivities (e.g., emails between Eli Hickox and Erin Madill), whereasthere are other contributors within the organization to activity 460. Asshown in FIG. 4C, prior to adding the contact identifier for Erin Madillto Eli Hickox's user-level blacklist, all of the activities appear inthe organization activity timeline. By contrast, after adding thecontact identifier for Erin Madill to Eli Hickox's user-level blacklist,the past activity scrubber 332 can scrub Eli Hickox's priorcontributions to each activity that is associated with the contactidentifier. As shown in FIG. 4D, all of the activities except activity460 no longer appear in the organization activity timeline because EliHickox was the sole contributor within the organization to thoseactivities, while activity 460 still appears in the organizationactivity timeline because Eli Hickox was not the sole contributor withinthe organization to activity 460. However, Eli Hickox's contributions toactivity 460 have been removed so that they do not appear in theorganization activity timeline to other users of the organization. Assuch, Eli Hickox's prior contributions to each activity that isassociated with the contact identifier no longer appear in theorganization activity timeline to other users of the organization.Contributions of other users of the organization to activity 460 remainin the organization activity timeline.

FIG. 5 is a flow chart that illustrates an exemplary method 500 forreal-time content blocking based on a user-level blacklist to prevent auser's contributions from appearing in new activities that are beingevaluated for addition to an organization activity timeline inaccordance with the disclosed embodiments. The method 500 can be used,for example, to selectively block a user's new contributions to anactivity from appearing in the organization activity timeline after useradds a contact to a user-level blacklist. As a preliminary matter, itshould be understood that steps of the method 500 are not necessarilylimiting, and that steps can be added, omitted, and/or performedsimultaneously without departing from the scope of the appended claims.It should be appreciated that the method 500 may include any number ofadditional or alternative tasks, that the tasks shown in FIG. 5 need notbe performed in the illustrated order, and that the method 500 may beincorporated into a more comprehensive procedure or process havingadditional functionality not described in detail herein. Moreover, oneor more of the tasks shown in FIG. 5 could potentially be omitted froman embodiment of the method 500 as long as the intended overallfunctionality remains intact. It should also be understood that theillustrated method 500 can be stopped at any time. The method 500 iscomputer-implemented in that various tasks or steps that are performedin connection with the method 500 may be performed by software,hardware, firmware, or any combination thereof. For illustrativepurposes, the following description of the method 500 may refer toelements mentioned above in connection with FIGS. 2 and 3A. In certainembodiments, some or all steps of this process, and/or substantiallyequivalent steps, are performed by execution of processor-readableinstructions stored or included on a processor-readable medium.

At some point prior to the start of the method 500, the user adds one ormore contact identifiers, such as email addresses, to a user-levelblacklist. This is represented in FIG. 5 by block 510. The method 500begins at 520, when an activity is created for the organization activitytimeline that includes a contact identifier on the user's of user-levelblacklist. The user who added the contact identifier to the blacklist orany other user who is part of the organization can create the activity.At 530, the real-time activity evaluator 330 determines whether thisuser is the sole contributor within the organization to the activity(e.g., determines whether the user and the particular contact are theonly participants for the activity, or if there are other contributorsto the activity who are also participants).

When the real-time activity evaluator 330 determines (at 530) that thisuser is the sole contributor (within the organization) to the activity,at 540, the real-time activity evaluator 330 blocks the activity so thatthe activity does not appear in the organization activity timeline toother users of the organization. By contrast, when the real-timeactivity evaluator 330 determines (at 530) that this user is not thesole contributor within the organization to the activity, at 550, thereal-time activity evaluator 330 blocks the user's contribution to theactivity so that any contributions by the user to the activity do notappear in the organization activity timeline to other users of theorganization so long as the contact identifier remains in that user'suser-level blacklist. However, contributions of other users of theorganization to that activity are allowed to remain and continue toappear in the organization activity timeline unless the other users alsohave that contact identifier in their user-level blacklist, in whichcase the contributions of those users would also be blocked or removedfrom the organization activity timeline.

FIG. 6A is a flow chart that illustrates an exemplary method 600 forretro-reactively adding a user's past contributions back into anorganization activity timeline when a user removes a contact identifierfrom a user-level blacklist in accordance with the disclosedembodiments. The method 600 allows a user to effectively reverse thescrub operations and add their contributions back into the activitytimeline when the user removes a contact identifier associated with aparticular contact from the user-level blacklist. As a preliminarymatter, it should be understood that steps of the method 600 are notnecessarily limiting, and that steps can be added, omitted, and/orperformed simultaneously without departing from the scope of theappended claims. It should be appreciated that the method 600 mayinclude any number of additional or alternative tasks, that the tasksshown in FIG. 6A need not be performed in the illustrated order, andthat the method 600 may be incorporated into a more comprehensiveprocedure or process having additional functionality not described indetail herein. Moreover, one or more of the tasks shown in FIG. 6A couldpotentially be omitted from an embodiment of the method 600 as long asthe intended overall functionality remains intact. It should also beunderstood that the illustrated method 600 can be stopped at any time.The method 600 is computer-implemented in that various tasks or stepsthat are performed in connection with the method 600 may be performed bysoftware, hardware, firmware, or any combination thereof. Forillustrative purposes, the following description of the method 600 mayrefer to elements mentioned above in connection with FIGS. 2 and 3A. Incertain embodiments, some or all steps of this process, and/orsubstantially equivalent steps, are performed by execution ofprocessor-readable instructions stored or included on aprocessor-readable medium.

Method 600 begins at 610, when a user of the organization removes acontact identifier associated with a particular contact from theuser-level blacklist (e.g., deletes an email address from theiruser-level blacklist). In response to removing, at 620, the pastactivity scrubber 332 evaluates past activities to identify pastactivities that were previously in the organization activity timelinethat include past contributions by the user and the contact identifierassociated with the particular contact. At 630, the past activityscrubber 332 adds the past activities back into the organizationactivity timeline so that past contributions by the user appear in theorganization activity timeline. As such, an activities that the user wasthe sole contributor to will also appear in the organization activitytimeline. In addition, although not illustrated in FIG. 6A, it should beappreciated that any new activities that include new contributions bythe user and the contact identifier will now appear in the organizationactivity timeline (e.g., blocking will now longer take place withrespect to any new activities that include new contributions by the userand the contact identifier).

FIG. 6B is a schematic diagram of simplified representations of acontributor activity timeline and an organization activity timelinebefore and after retro-reactively adding some of the user's pastcontributions back into the organization activity timeline in accordancewith the disclosed embodiments. FIG. 6B shows the opposite scenarioillustrated in FIG. 4B.

Here, it assumed that a user (User0) of the organization had previouslyadded a contact identifier to their user-level blacklist, and that User0has contributed to activities 642, 644, 648 are associated with thatcontact identifier. As shown, prior to removing the contact identifierto User0's user-level blacklist, activities 642, 644 do not appear inthe organization activity timeline, and with respect to activity 648,User0's contributions to activity 648 have been removed so that they donot appear in the organization activity timeline to other users of theorganization. By contrast, after removing the contact identifier fromUser0's user-level blacklist, the past activity scrubber 332 addsUser0's prior contributions to each activity 642, 644, 648 that isassociated with the contact identifier back into the organizationactivity timeline. Activities 642, 644 now appear in the organizationactivity timeline because User0 was the sole contributor within theorganization to those activities, while User0's contributions toactivity 648 have been added back into that activity so that they nowappear in the organization activity timeline to other users of theorganization. As such, User0's prior contributions to each activity thatis associated with the contact identifier now appear in the organizationactivity timeline to other users of the organization (unless the otherusers also have the contact identifier in their user-level blacklist, inwhich case the contributions of those users would also be removed fromthe activity timeline).

FIG. 7A is a flow chart that illustrates an exemplary real-time activityevaluation method 700 for determining whether new activities are allowedto appear in an organization activity timeline based on checking ofvarious organization-level blacklists in accordance with the disclosedembodiments. As a preliminary matter, it should be understood that stepsof the method 700 are not necessarily limiting, and that steps can beadded, omitted, and/or performed simultaneously without departing fromthe scope of the appended claims. It should be appreciated that themethod 700 may include any number of additional or alternative tasks,that the tasks shown in FIG. 7A need not be performed in the illustratedorder, and that the method 700 may be incorporated into a morecomprehensive procedure or process having additional functionality notdescribed in detail herein. Moreover, one or more of the tasks shown inFIG. 7A could potentially be omitted from an embodiment of the method700 as long as the intended overall functionality remains intact. Itshould also be understood that the illustrated method 700 can be stoppedat any time. The method 700 is computer-implemented in that varioustasks or steps that are performed in connection with the method 700 maybe performed by software, hardware, firmware, or any combinationthereof. For illustrative purposes, the following description of themethod 700 may refer to elements mentioned above in connection withFIGS. 2 and 3A. In certain embodiments, some or all steps of thisprocess, and/or substantially equivalent steps, are performed byexecution of processor-readable instructions stored or included on aprocessor-readable medium.

The method 700 begins at 702, when an activity is created and evaluatedfor inclusion in the organization activity timeline. The activity can beevaluated against organization-level blacklists for specific contactsspecified by the administrator, organization-level external domainblacklists for specific external domains specified by the administrator,and organization-level internal domain blacklists for specific internaldomains specified by the administrator.

At 704, the real-time activity evaluator 330 can evaluate the activityagainst the organization-level blacklist to determine whether theactivity includes a contribution from any contact identifiers includedin the organization-level blacklist. The administrator of theorganization can include any number of contact identifiers each of whichis associated with a particular contact. When the real-time activityevaluator 330 determines (at 704) that the activity does not include acontribution from any contact identifiers included in theorganization-level blacklist, the method proceeds to 706. When thereal-time activity evaluator 330 determines (at 704) that the activitydoes include a contribution from one or more contact identifiersincluded in the organization-level blacklist, the method proceeds to710.

At 706, the real-time activity evaluator 330 can evaluate the activityagainst the organization-level external domain blacklist, and determinewhether the activity includes any contribution having an external domainspecified in the organization-level external domain blacklist. Theadministrator of the organization can include any number of externaldomains in the organization-level external domain blacklist each ofwhich is associated with a particular external domain that is externalto the organization. When the real-time activity evaluator 330determines (at 706) that the activity does not include any contributionhaving an external domain specified in the organization-level externaldomain blacklist, the method proceeds to 708. When the real-timeactivity evaluator 330 determines (at 706) that the activity doesinclude any contribution having an external domain specified in theorganization-level external domain blacklist, the method proceeds to710.

At 708, the real-time activity evaluator 330 can evaluate the activityagainst the organization-level internal domain blacklist, and determinewhether all contributions to the activity have the internal domainspecified in the organization-level internal domain blacklist. Theadministrator of the organization can include the internal domain of theorganization and any number of aliases of that internal domain in theorganization-level internal domain blacklist. As such, at 708, thereal-time activity evaluator 330 can evaluate the activity against theorganization-level internal domain blacklist, and determine whether allcontributions to the activity belong to an internal domain or alias ofthe internal domain of the organization as specified in theorganization-level internal domain blacklist.

When the real-time activity evaluator 330 determines (at 708) that allcontributions to the activity belong to an internal domain or alias, themethod proceeds to 710. At 710, the real-time activity evaluator 330performs a hard-delete and blocks the activity from appearing in theorganization activity timeline. Because the activity is hard-deleted theactivity is not allowed to be retroactively added back into theorganization activity timeline at a later time.

When the real-time activity evaluator 330 determines (at 708) that allcontributions to the activity do not belong to an internal domain oralias, the method proceeds to 712, where the real-time activityevaluator 330 allows the activity and all contributions to the activityto appear in the organization activity timeline.

Whenever the organization-level blacklist, the organization-levelexternal domain blacklist, or the organization-level internal domainblacklist are updated by the administrator, the past activity scrubber332 can retroactively perform scrubbing to remove past activities fromthe organization activity timeline. As will now be described withreference to FIGS. 7B-7D, the past activity scrubber 332 can search theorganization activity timeline to find past activities that are to bedeleted from the organization activity timeline, and then hard-deletesuch identified past activities from the organization activity timelineso that the identified past activities no longer appear in theorganization activity timeline and are not allowed to be added back intothe organization activity timeline at a later time.

FIG. 7B is a flow chart that illustrates an exemplary method 710 forretroactively scrubbing a past activities from an organization activitytimeline when the administrator adds a contact identifier to anorganization-level blacklist in accordance with the disclosedembodiments. As a preliminary matter, it should be understood that stepsof the method 710 are not necessarily limiting, and that steps can beadded, omitted, and/or performed simultaneously without departing fromthe scope of the appended claims. It should be appreciated that themethod 710 may include any number of additional or alternative tasks,that the tasks shown in FIG. 7B need not be performed in the illustratedorder, and that the method 710 may be incorporated into a morecomprehensive procedure or process having additional functionality notdescribed in detail herein. Moreover, one or more of the tasks shown inFIG. 7B could potentially be omitted from an embodiment of the method710 as long as the intended overall functionality remains intact. Itshould also be understood that the illustrated method 710 can be stoppedat any time. The method 710 is computer-implemented in that varioustasks or steps that are performed in connection with the method 710 maybe performed by software, hardware, firmware, or any combinationthereof. For illustrative purposes, the following description of themethod 710 may refer to elements mentioned above in connection withFIGS. 2 and 3A. In certain embodiments, some or all steps of thisprocess, and/or substantially equivalent steps, are performed byexecution of processor-readable instructions stored or included on aprocessor-readable medium.

The method 710 begins at 712, when a new contact identifier for aspecific contact is added to an organization-level blacklist by theadministrator. This triggers evaluation of past activities against theorganization-level blacklist so that activities can be removed or“scrubbed from” the organization activity timeline.

At 714, the past activity scrubber 332 can evaluate the next activity inthe organization activity timeline against the organization-levelblacklist to determine whether the activity includes a contribution fromthe new contact identifier that was added to the organization-levelblacklist.

When the past activity scrubber 332 determines (at 714) that theactivity does include a contribution from the new contact identifierthat was added to the organization-level blacklist, the method proceedsto 716, where the past activity scrubber 332 performs a hard-delete andremoves the activity from the organization activity timeline so that theactivity no longer appears in the organization activity timeline.Because the activity is hard-deleted the activity is not allowed to beretroactively added back into the organization activity timeline at alater time.

When the past activity scrubber 332 determines (at 714) that theactivity does not include a contribution from the new contact identifierthat was added to the organization-level blacklist, the method proceedsto 718, where the past activity scrubber 332 allows the activity and allcontributions to the activity to continue to appear in the organizationactivity timeline.

Following 716 and 718, the past activity scrubber 332 determines (at720) whether anymore activities remain in the organization activitytimeline to be evaluated (e.g., that have not been evaluated or changedsince prior evaluation). When the past activity scrubber 332 determines(at 720) that more activities remain in the organization activitytimeline to evaluate, the method 710 loops back to 714. By contrast,when the past activity scrubber 332 determines (at 720) that no moreactivities remain in the organization activity timeline to be evaluated,the method 710 ends at 722 until it is triggered again.

FIG. 7C is a flow chart that illustrates an exemplary method 730 forretroactively scrubbing a past activities from an organization activitytimeline when the administrator adds an external domain to anorganization-level external domain blacklist in accordance with thedisclosed embodiments. As a preliminary matter, it should be understoodthat steps of the method 730 are not necessarily limiting, and thatsteps can be added, omitted, and/or performed simultaneously withoutdeparting from the scope of the appended claims. It should beappreciated that the method 730 may include any number of additional oralternative tasks, that the tasks shown in FIG. 7C need not be performedin the illustrated order, and that the method 730 may be incorporatedinto a more comprehensive procedure or process having additionalfunctionality not described in detail herein. Moreover, one or more ofthe tasks shown in FIG. 7C could potentially be omitted from anembodiment of the method 730 as long as the intended overallfunctionality remains intact. It should also be understood that theillustrated method 730 can be stopped at any time. The method 730 iscomputer-implemented in that various tasks or steps that are performedin connection with the method 730 may be performed by software,hardware, firmware, or any combination thereof. For illustrativepurposes, the following description of the method 730 may refer toelements mentioned above in connection with FIGS. 2 and 3A. In certainembodiments, some or all steps of this process, and/or substantiallyequivalent steps, are performed by execution of processor-readableinstructions stored or included on a processor-readable medium.

The method 730 begins at 732, when a new external domain is added to anorganization-level external domain blacklist by the administrator. Thistriggers evaluation of past activities against the organization-levelexternal domain blacklist so that activities can be removed or “scrubbedfrom” the organization activity timeline.

At 734, the past activity scrubber 332 can evaluate the next activity inthe organization activity timeline against the organization-levelexternal domain blacklist to determine whether the activity includes anycontribution from or having the new external domain that was added tothe organization-level external domain blacklist.

When the past activity scrubber 332 determines (at 734) that theactivity does include any contribution from or having the new externaldomain that was added to the organization-level external domainblacklist, the method proceeds to 736, where the past activity scrubber332 performs a hard-delete and removes the activity from theorganization activity timeline so that the activity no longer appears inthe organization activity timeline. Because the activity is hard-deletedthe activity is not allowed to be retroactively added back into theorganization activity timeline at a later time.

When the past activity scrubber 332 determines (at 734) that theactivity does not include any contribution from or having the newexternal domain that was added to the organization-level external domainblacklist, the method proceeds to 738, where the past activity scrubber332 allows the activity and all contributions to the activity tocontinue to appear in the organization activity timeline.

Following 736 and 738, the past activity scrubber 332 determines (at740) whether anymore activities remain in the organization activitytimeline to be evaluated (e.g., that have not been evaluated or changedsince prior evaluation). When the past activity scrubber 332 determines(at 740) that more activities remain in the organization activitytimeline to evaluate, the method 730 loops back to 734. By contrast,when the past activity scrubber 332 determines (at 740) that no moreactivities remain in the organization activity timeline to be evaluated,the method 730 ends at 722 until it is triggered again.

Thus, if the past activity scrubber 332 searches the organizationactivity timeline and finds one or more past activities that include anycontribution having an external domain included in theorganization-level external domain blacklist, then the past activityscrubber 332 can remove the identified past activities (that include anexternal domain included in the organization-level external domainblacklist) from the organization activity timeline by performing ahard-delete so that they no longer appear in the organization activitytimeline and are not allowed to be added back into the organizationactivity timeline at a later time.

FIG. 7D is a flow chart that illustrates an exemplary method 750 forretroactively scrubbing a past activities from an organization activitytimeline when the administrator adds an internal domain to anorganization-level internal domain blacklist in accordance with thedisclosed embodiments. As a preliminary matter, it should be understoodthat steps of the method 750 are not necessarily limiting, and thatsteps can be added, omitted, and/or performed simultaneously withoutdeparting from the scope of the appended claims. It should beappreciated that the method 750 may include any number of additional oralternative tasks, that the tasks shown in FIG. 7D need not be performedin the illustrated order, and that the method 750 may be incorporatedinto a more comprehensive procedure or process having additionalfunctionality not described in detail herein. Moreover, one or more ofthe tasks shown in FIG. 7D could potentially be omitted from anembodiment of the method 750 as long as the intended overallfunctionality remains intact. It should also be understood that theillustrated method 750 can be stopped at any time. The method 750 iscomputer-implemented in that various tasks or steps that are performedin connection with the method 750 may be performed by software,hardware, firmware, or any combination thereof. For illustrativepurposes, the following description of the method 750 may refer toelements mentioned above in connection with FIGS. 2 and 3A. In certainembodiments, some or all steps of this process, and/or substantiallyequivalent steps, are performed by execution of processor-readableinstructions stored or included on a processor-readable medium.

The method 750 begins at 752, when a new internal domain is added to anorganization-level internal domain blacklist by the administrator. Thistriggers evaluation of past activities against the organization-levelinternal domain blacklist so that activities can be removed or “scrubbedfrom” the organization activity timeline.

At 754, the past activity scrubber 332 can evaluate the next activity inthe organization activity timeline against the organization-levelinternal domain blacklist to determine whether all contributions to thisactivity have an internal domain of the organization specified in theorganization-level internal domain blacklist including the new internaldomain that was added to the organization-level internal domainblacklist. As noted above, the administrator of the organization caninclude the internal domain of the organization and any number ofaliases of that internal domain in the organization-level internaldomain blacklist. As such, at 754, the past activity scrubber 332 canevaluate the activity against the organization-level internal domainblacklist, and determine whether all contributions to the activitybelong to an internal domain or alias of the internal domain of theorganization as specified in the organization-level internal domainblacklist.

When the past activity scrubber 332 determines (at 754) that allcontributions to this activity have an internal domain of theorganization (as specified in the organization-level internal domainblacklist), the method proceeds to 756, where the past activity scrubber332 performs a hard-delete and removes the activity from theorganization activity timeline so that the activity no longer appears inthe organization activity timeline. Because the activity is hard-deletedthe activity is not allowed to be retroactively added back into theorganization activity timeline at a later time.

When the past activity scrubber 332 determines (at 754) that that allcontributions to this activity do not have an internal domain of theorganization (as specified in the organization-level internal domainblacklist), the method proceeds to 758, where the past activity scrubber332 allows the activity and all contributions to the activity tocontinue to appear in the organization activity timeline.

Following 756 and 758, the past activity scrubber 332 determines (at760) whether anymore activities remain in the organization activitytimeline to be evaluated (e.g., that have not been evaluated or changedsince prior evaluation). When the past activity scrubber 332 determines(at 760) that more activities remain in the organization activitytimeline to evaluate, the method 750 loops back to 754. By contrast,when the past activity scrubber 332 determines (at 760) that no moreactivities remain in the organization activity timeline to be evaluated,the method 750 ends at 762 until it is triggered again.

Thus, if the past activity scrubber 332 searches the organizationactivity timeline and finds one or more past activities where allcontributions are from one or more internal domains included in theorganization-level internal domain blacklist, then the past activityscrubber 332 can remove those identified past activities from theorganization activity timeline by performing a hard-delete so that theyno longer appear in the organization activity timeline and are notallowed to be added back into the organization activity timeline at alater time.

FIG. 7E is a schematic diagram of simplified representations of anorganization activity timeline before an administrator adds a contactidentifier (Addr₀) to an organization-level blacklist and theorganization activity timeline after the administrator adds the contactidentifier (Addr₀) to an organization-level blacklist in accordance withthe disclosed embodiments.

Before the administrator adds a contact identifier (Addr_(o)) to theorganization-level blacklist, organization activity timeline includedactivities 772, 774, 778, 780, 782, 784, 786, 788. When theadministrator adds a contact identifier (Addr₀) to theorganization-level blacklist, this triggers evaluation of pastactivities 772, 774, 778, 780, 782, 784, 786, 788 against theorganization-level blacklist by the past activity scrubber 332. In thisexample, the past activity scrubber 332 evaluates each of the activitiesin the organization activity timeline against the organization-levelblacklist and determines that activities 774, 778, 780, 786 include acontribution from the new contact identifier (Addr₀) that was added tothe organization-level blacklist, and performs a hard-delete to removeactivities 774, 778, 780, 786 from the organization activity timeline sothat they no longer appears in the organization activity timeline.Because the activities 774, 778, 780, 786 are hard-deleted they are notallowed to be retroactively added back into the organization activitytimeline at a later time.

FIG. 7F is a screenshot that shows an example of an organizationactivity timeline for notifications@github.com before an administratoradds the external domain github.com to an organization-level externaldomain blacklist in accordance with the disclosed embodiments. Theorganization activity timeline includes various activities collectivelyshown as 790. FIG. 7G is a screenshot that shows the organizationactivity timeline for notifications@github.com after the administratoradds the external domain github.com to the organization-level externaldomain blacklist, and that all of the activities from FIG. 7F have beenhard-deleted.

FIG. 7H is a screenshot that shows an example of an organizationactivity timeline for eli@salesforceiq.com before an administrator addsthe internal domain salesforceiq.com to an organization-level internaldomain blacklist in accordance with the disclosed embodiments. As shownin FIG. 7H, the organization activity timeline includes variousactivities including five emails collectively shown as 792, an email794, and two meetings 796, 798. When a new internal domainsalesforceiq.com is added to the organization-level internal domainblacklist by the administrator, this triggers evaluation of pastactivities against the organization-level internal domain blacklist sothat activities can be removed or “scrubbed from” the organizationactivity timeline. As described above, the past activity scrubber 332can evaluate each activity in the organization activity timeline againstthe organization-level internal domain blacklist to determine whetherall contributions to this activity have an internal domainsalesforceiq.com or any number of aliases of that internal domainsalesforceiq.com that are specified the organization-level internaldomain blacklist. In this example, it is assumed that for each of theactivities shown in FIG. 7H, except activity 794, the past activityscrubber 332 determines (at 754) that all contributions to this activityhave an internal domain salesforceiq.com. By contrast, it is assumed inthis example, that the past activity scrubber 332 has determined thatall contributions to activity 794 do not have an internal domainsalesforceiq.com.

FIG. 7I is a screenshot that shows an example of the organizationactivity timeline for eli@salesforceiq.com after an administrator addsthe internal domain salesforceiq.com to the organization-level internaldomain blacklist in accordance with the disclosed embodiments. As shownin FIG. 7I, the past activity scrubber 332 has performed a hard-deleteand removed the activities 792, 796, 798 from the organization activitytimeline so that the activities 792, 796, 798 no longer appears in theorganization activity timeline, but allows the activity 794 and allcontributions to the activity to continue to appear in the organizationactivity timeline. Because the activities 792, 796, 798 are hard-deletedthe activities 792, 796, 798 are not allowed to be retroactively addedback into the organization activity timeline at a later time.

The following description is of one example of a system in which thefeatures described above may be implemented. The components of thesystem described below are merely one example and should not beconstrued as limiting. The features described above with respect toFIGS. 1-7I may be implemented in any other type of computingenvironment, such as one with multiple servers, one with a singleserver, a multi-tenant server environment, a single-tenant serverenvironment, or some combination of the above.

FIG. 8 shows a block diagram of an example of an environment 810 inwhich an on-demand database service can be used in accordance with someimplementations. The environment 810 includes user systems 812, anetwork 814, a database system 816 (also referred to herein as a“cloud-based system”), a processor system 817, an application platform818, a network interface 820, tenant database 822 for storing tenantdata 823, system database 824 for storing system data 825, program code826 for implementing various functions of the system 816, and processspace 828 for executing database system processes and tenant-specificprocesses, such as running applications as part of an applicationhosting service. In some other implementations, environment 810 may nothave all of these components or systems, or may have other components orsystems instead of, or in addition to, those listed above.

In some implementations, the environment 810 is an environment in whichan on-demand database service exists. An on-demand database service,such as that which can be implemented using the system 816, is a servicethat is made available to users outside of the enterprise(s) that own,maintain or provide access to the system 816. As described above, suchusers generally do not need to be concerned with building or maintainingthe system 816. Instead, resources provided by the system 816 may beavailable for such users' use when the users need services provided bythe system 816; that is, on the demand of the users. Some on-demanddatabase services can store information from one or more tenants intotables of a common database image to form a multi-tenant database system(MTS). The term “multi-tenant database system” can refer to thosesystems in which various elements of hardware and software of a databasesystem may be shared by one or more customers or tenants. For example, agiven application server may simultaneously process requests for a greatnumber of customers, and a given database table may store rows of datasuch as feed items for a potentially much greater number of customers. Adatabase image can include one or more database objects. A relationaldatabase management system (RDBMS) or the equivalent can execute storageand retrieval of information against the database object(s).

Application platform 818 can be a framework that allows the applicationsof system 816 to execute, such as the hardware or softwareinfrastructure of the system 816. In some implementations, theapplication platform 818 enables the creation, management and executionof one or more applications developed by the provider of the on-demanddatabase service, users accessing the on-demand database service viauser systems 812, or third party application developers accessing theon-demand database service via user systems 812.

In some implementations, the system 816 implements a web-based customerrelationship management (CRM) system. For example, in some suchimplementations, the system 816 includes application servers configuredto implement and execute CRM software applications as well as providerelated data, code, forms, renderable web pages and documents and otherinformation to and from user systems 812 and to store to, and retrievefrom, a database system related data, objects, and Web page content. Insome MTS implementations, data for multiple tenants may be stored in thesame physical database object in tenant database 822. In some suchimplementations, tenant data is arranged in the storage medium(s) oftenant database 822 so that data of one tenant is kept logicallyseparate from that of other tenants so that one tenant does not haveaccess to another tenant's data, unless such data is expressly shared.The system 816 also implements applications other than, or in additionto, a CRM application. For example, the system 816 can provide tenantaccess to multiple hosted (standard and custom) applications, includinga CRM application. User (or third party developer) applications, whichmay or may not include CRM, may be supported by the application platform818. The application platform 818 manages the creation and storage ofthe applications into one or more database objects and the execution ofthe applications in one or more virtual machines in the process space ofthe system 816.

According to some implementations, each system 816 is configured toprovide web pages, forms, applications, data and media content to user(client) systems 812 to support the access by user systems 812 astenants of system 816. As such, system 816 provides security mechanismsto keep each tenant's data separate unless the data is shared. If morethan one MTS is used, they may be located in close proximity to oneanother (for example, in a server farm located in a single building orcampus), or they may be distributed at locations remote from one another(for example, one or more servers located in city A and one or moreservers located in city B). As used herein, each MTS could include oneor more logically or physically connected servers distributed locally oracross one or more geographic locations. Additionally, the term “server”is meant to refer to a computing device or system, including processinghardware and process space(s), an associated storage medium such as amemory device or database, and, in some instances, a databaseapplication (for example, OODBMS or RDBMS) as is well known in the art.It should also be understood that “server system” and “server” are oftenused interchangeably herein. Similarly, the database objects describedherein can be implemented as part of a single database, a distributeddatabase, a collection of distributed databases, a database withredundant online or offline backups or other redundancies, etc., and caninclude a distributed database or storage network and associatedprocessing intelligence.

The network 814 can be or include any network or combination of networksof systems or devices that communicate with one another. For example,the network 814 can be or include any one or any combination of a LAN(local area network), WAN (wide area network), telephone network,wireless network, cellular network, point-to-point network, starnetwork, token ring network, hub network, or other appropriateconfiguration. The network 814 can include a TCP/IP (Transfer ControlProtocol and Internet Protocol) network, such as the global internetworkof networks often referred to as the “Internet” (with a capital “I”).The Internet will be used in many of the examples herein. However, itshould be understood that the networks that the disclosedimplementations can use are not so limited, although TCP/IP is afrequently implemented protocol.

The user systems 812 can communicate with system 816 using TCP/IP and,at a higher network level, other common Internet protocols tocommunicate, such as HTTP, FTP, AFS, WAP, etc. In an example where HTTPis used, each user system 812 can include an HTTP client commonlyreferred to as a “web browser” or simply a “browser” for sending andreceiving HTTP signals to and from an HTTP server of the system 816.Such an HTTP server can be implemented as the sole network interface 820between the system 816 and the network 814, but other techniques can beused in addition to or instead of these techniques. In someimplementations, the network interface 820 between the system 816 andthe network 814 includes load sharing functionality, such as round-robinHTTP request distributors to balance loads and distribute incoming HTTPrequests evenly over a number of servers. In MTS implementations, eachof the servers can have access to the MTS data; however, otheralternative configurations may be used instead.

The user systems 812 can be implemented as any computing device(s) orother data processing apparatus or systems usable by users to access thedatabase system 816. For example, any of user systems 812 can be adesktop computer, a work station, a laptop computer, a tablet computer,a handheld computing device, a mobile cellular phone (for example, a“smartphone”), or any other Wi-Fi-enabled device, wireless accessprotocol (WAP)-enabled device, or other computing device capable ofinterfacing directly or indirectly to the Internet or other network. Theterms “user system” and “computing device” are used interchangeablyherein with one another and with the term “computer.” As describedabove, each user system 812 typically executes an HTTP client, forexample, a web browsing (or simply “browsing”) program, such as a webbrowser based on the WebKit platform, Microsoft's Internet Explorerbrowser, Netscape's Navigator browser, Opera's browser, Mozilla'sFirefox browser, or a WAP-enabled browser in the case of a cellularphone, PDA or other wireless device, or the like, allowing a user (forexample, a subscriber of on-demand services provided by the system 816)of the user system 812 to access, process and view information, pagesand applications available to it from the system 816 over the network814.

Each user system 812 also typically includes one or more user inputdevices, such as a keyboard, a mouse, a trackball, a touch pad, a touchscreen, a pen or stylus or the like, for interacting with a graphicaluser interface (GUI) provided by the browser on a display (for example,a monitor screen, liquid crystal display (LCD), light-emitting diode(LED) display, among other possibilities) of the user system 812 inconjunction with pages, forms, applications and other informationprovided by the system 816 or other systems or servers. For example, theuser interface device can be used to access data and applications hostedby system 816, and to perform searches on stored data, and otherwiseallow a user to interact with various GUI pages that may be presented toa user. As discussed above, implementations are suitable for use withthe Internet, although other networks can be used instead of or inaddition to the Internet, such as an intranet, an extranet, a virtualprivate network (VPN), a non-TCP/IP based network, any LAN or WAN or thelike.

The users of user systems 812 may differ in their respective capacities,and the capacity of a particular user system 812 can be entirelydetermined by permissions (permission levels) for the current user ofsuch user system. For example, where a salesperson is using a particularuser system 812 to interact with the system 816, that user system canhave the capacities allotted to the salesperson. However, while anadministrator is using that user system 812 to interact with the system816, that user system can have the capacities allotted to thatadministrator. Where a hierarchical role model is used, users at onepermission level can have access to applications, data, and databaseinformation accessible by a lower permission level user, but may nothave access to certain applications, database information, and dataaccessible by a user at a higher permission level. Thus, different usersgenerally will have different capabilities with regard to accessing andmodifying application and database information, depending on the users'respective security or permission levels (also referred to as“authorizations”).

According to some implementations, each user system 812 and some or allof its components are operator-configurable using applications, such asa browser, including computer code executed using a central processingunit (CPU) such as an Intel Pentium® processor or the like. Similarly,the system 816 (and additional instances of an MTS, where more than oneis present) and all of its components can be operator-configurable usingapplication(s) including computer code to run using the processor system817, which may be implemented to include a CPU, which may include anIntel Pentium® processor or the like, or multiple CPUs.

The system 816 includes tangible computer-readable media havingnon-transitory instructions stored thereon/in that are executable by orused to program a server or other computing system (or collection ofsuch servers or computing systems) to perform some of the implementationof processes described herein. For example, computer program code 826can implement instructions for operating and configuring the system 816to intercommunicate and to process web pages, applications and otherdata and media content as described herein. In some implementations, thecomputer code 826 can be downloadable and stored on a hard disk, but theentire program code, or portions thereof, also can be stored in anyother volatile or non-volatile memory medium or device as is well known,such as a ROM or RAM, or provided on any media capable of storingprogram code, such as any type of rotating media including floppy disks,optical discs, digital versatile disks (DVD), compact disks (CD),microdrives, and magneto-optical disks, and magnetic or optical cards,nanosystems (including molecular memory ICs), or any other type ofcomputer-readable medium or device suitable for storing instructions ordata. Additionally, the entire program code, or portions thereof, may betransmitted and downloaded from a software source over a transmissionmedium, for example, over the Internet, or from another server, as iswell known, or transmitted over any other existing network connection asis well known (for example, extranet, VPN, LAN, etc.) using anycommunication medium and protocols (for example, TCP/IP, HTTP, HTTPS,Ethernet, etc.) as are well known. It will also be appreciated thatcomputer code for the disclosed implementations can be realized in anyprogramming language that can be executed on a server or other computingsystem such as, for example, C, C++, HTML, any other markup language,Java™, JavaScript, ActiveX, any other scripting language, such asVBScript, and many other programming languages as are well known may beused. (Java™ is a trademark of Sun Microsystems, Inc.).

FIG. 9 shows a block diagram of example implementations of elements ofFIG. 8 and example interconnections between these elements according tosome implementations. That is, FIG. 9 also illustrates environment 810,but FIG. 9, various elements of the system 816 and variousinterconnections between such elements are shown with more specificityaccording to some more specific implementations. Elements from FIG. 8that are also shown in FIG. 9 will use the same reference numbers inFIG. 9 as were used in FIG. 8. Additionally, in FIG. 9, the user system812 includes a processor system 912A, a memory system 912B, an inputsystem 912C, and an output system 912D. The processor system 912A caninclude any suitable combination of one or more processors. The memorysystem 912B can include any suitable combination of one or more memorydevices. The input system 912C can include any suitable combination ofinput devices, such as one or more touchscreen interfaces, keyboards,mice, trackballs, scanners, cameras, or interfaces to networks. Theoutput system 912D can include any suitable combination of outputdevices, such as one or more display devices, printers, or interfaces tonetworks.

In FIG. 9, the network interface 820 of FIG. 8 is implemented as a setof HTTP application servers 900 ₁-1400 _(N). Each application server900, also referred to herein as an “app server,” is configured tocommunicate with tenant database 822 and the tenant data 923 therein, aswell as system database 824 and the system data 925 therein, to serverequests received from the user systems 912. The tenant data 923 can bedivided into individual tenant storage spaces 913, which can bephysically or logically arranged or divided. Within each tenant storagespace 913, tenant data 914 and application metadata 916 can similarly beallocated for each user. For example, a copy of a user's most recentlyused (MRU) items can be stored to user storage 914. Similarly, a copy ofMRU items for an entire organization that is a tenant can be stored totenant storage space 913.

The process space 828 includes system process space 902, individualtenant process spaces 904 and a tenant management process space 910. Theapplication platform 818 includes an application setup mechanism 938that supports application developers' creation and management ofapplications. Such applications and others can be saved as metadata intotenant database 822 by save routines 936 for execution by subscribers asone or more tenant process spaces 904 managed by tenant managementprocess 910, for example. Invocations to such applications can be codedusing PL/SOQL 934, which provides a programming language style interfaceextension to API 932. A detailed description of some PL/SOQL languageimplementations is discussed in commonly assigned U.S. Pat. No.7,730,478, titled METHOD AND SYSTEM FOR ALLOWING ACCESS TO DEVELOPEDAPPLICATIONS VIA A MULTI-TENANT ON-DEMAND DATABASE SERVICE, by CraigWeissman, issued on Jun. 1, 2010, and hereby incorporated by referencein its entirety and for all purposes. Invocations to applications can bedetected by one or more system processes, which manage retrievingapplication metadata 816 for the subscriber making the invocation andexecuting the metadata as an application in a virtual machine.

The system 816 of FIG. 9 also includes a user interface (UI) 930 and anapplication programming interface (API) 932 to system 816 residentprocesses to users or developers at user systems 912. In some otherimplementations, the environment 810 may not have the same elements asthose listed above or may have other elements instead of, or in additionto, those listed above.

Each application server 900 can be communicably coupled with tenantdatabase 822 and system database 824, for example, having access totenant data 923 and system data 925, respectively, via a differentnetwork connection. For example, one application server 900 ₁ can becoupled via the network 814 (for example, the Internet), anotherapplication server 900 _(N) can be coupled via a direct network link,and another application server (not illustrated) can be coupled by yet adifferent network connection. Transfer Control Protocol and InternetProtocol (TCP/IP) are examples of typical protocols that can be used forcommunicating between application servers 900 and the system 816.However, it will be apparent to one skilled in the art that othertransport protocols can be used to optimize the system 816 depending onthe network interconnections used.

In some implementations, each application server 900 is configured tohandle requests for any user associated with any organization that is atenant of the system 816. Because it can be desirable to be able to addand remove application servers 900 from the server pool at any time andfor various reasons, in some implementations there is no server affinityfor a user or organization to a specific application server 900. In somesuch implementations, an interface system implementing a load balancingfunction (for example, an F5 Big-IP load balancer) is communicablycoupled between the application servers 900 and the user systems 912 todistribute requests to the application servers 900. In oneimplementation, the load balancer uses a least-connections algorithm toroute user requests to the application servers 900. Other examples ofload balancing algorithms, such as round robin andobserved-response-time, also can be used. For example, in someinstances, three consecutive requests from the same user could hit threedifferent application servers 900, and three requests from differentusers could hit the same application server 900. In this manner, by wayof example, system 816 can be a multi-tenant system in which system 816handles storage of, and access to, different objects, data andapplications across disparate users and organizations.

In one example storage use case, one tenant can be a company thatemploys a sales force where each salesperson uses system 816 to manageaspects of their sales. A user can maintain contact data, leads data,customer follow-up data, performance data, goals and progress data,etc., all applicable to that user's personal sales process (for example,in tenant database 822). In an example of a MTS arrangement, because allof the data and the applications to access, view, modify, report,transmit, calculate, etc., can be maintained and accessed by a usersystem 912 having little more than network access, the user can managehis or her sales efforts and cycles from any of many different usersystems. For example, when a salesperson is visiting a customer and thecustomer has Internet access in their lobby, the salesperson can obtaincritical updates regarding that customer while waiting for the customerto arrive in the lobby.

While each user's data can be stored separately from other users' dataregardless of the employers of each user, some data can beorganization-wide data shared or accessible by several users or all ofthe users for a given organization that is a tenant. Thus, there can besome data structures managed by system 816 that are allocated at thetenant level while other data structures can be managed at the userlevel. Because an MTS can support multiple tenants including possiblecompetitors, the MTS can have security protocols that keep data,applications, and application use separate. Also, because many tenantsmay opt for access to an MTS rather than maintain their own system,redundancy, up-time, and backup are additional functions that can beimplemented in the MTS. In addition to user-specific data andtenant-specific data, the system 816 also can maintain system level datausable by multiple tenants or other data. Such system level data caninclude industry reports, news, postings, and the like that are sharableamong tenants.

In some implementations, the user systems 912 (which also can be clientsystems) communicate with the application servers 900 to request andupdate system-level and tenant-level data from the system 816. Suchrequests and updates can involve sending one or more queries to tenantdatabase 822 or system database 824. The system 816 (for example, anapplication server 900 in the system 816) can automatically generate oneor more SQL statements (for example, one or more SQL queries) designedto access the desired information. System database 824 can generatequery plans to access the requested data from the database. The term“query plan” generally may refer to one or more operations used toaccess information in a database system.

Each database can generally be viewed as a collection of objects, suchas a set of logical tables, containing data fitted into predefined orcustomizable categories. A “table” is one representation of a dataobject, and may be used herein to simplify the conceptual description ofobjects and custom objects according to some implementations. It shouldbe understood that “table” and “object” may be used interchangeablyherein. Each table generally contains one or more data categorieslogically arranged as columns or fields in a viewable schema. Each rowor element of a table can contain an instance of data for each categorydefined by the fields. For example, a CRM database can include a tablethat describes a customer with fields for basic contact information suchas name, address, phone number, fax number, etc. Another table candescribe a purchase order, including fields for information such ascustomer, product, sale price, date, etc. In some MTS implementations,standard entity tables can be provided for use by all tenants. For CRMdatabase applications, such standard entities can include tables forcase, account, contact, lead, and opportunity data objects, eachcontaining pre-defined fields. As used herein, the term “entity” alsomay be used interchangeably with “object” and “table.”

In some MTS implementations, tenants are allowed to create and storecustom objects, or may be allowed to customize standard entities orobjects, for example by creating custom fields for standard objects,including custom index fields. Commonly assigned U.S. Pat. No.7,779,039, titled CUSTOM ENTITIES AND FIELDS IN A MULTI-TENANT DATABASESYSTEM, by Weissman et al., issued on Aug. 17, 2010, and herebyincorporated by reference in its entirety and for all purposes, teachessystems and methods for creating custom objects as well as customizingstandard objects in a multi-tenant database system. In someimplementations, for example, all custom entity data rows are stored ina single multi-tenant physical table, which may contain multiple logicaltables per organization. It is transparent to customers that theirmultiple “tables” are in fact stored in one large table or that theirdata may be stored in the same table as the data of other customers.

FIG. 10A shows a system diagram illustrating example architecturalcomponents of an on-demand database service environment 1000 accordingto some implementations. A client machine communicably connected withthe cloud 1004, generally referring to one or more networks incombination, as described herein, can communicate with the on-demanddatabase service environment 1000 via one or more edge routers 1008 and1012. A client machine can be any of the examples of user systems 12described above. The edge routers can communicate with one or more coreswitches 1020 and 1024 through a firewall 1016. The core switches cancommunicate with a load balancer 1028, which can distribute server loadover different pods, such as the pods 1040 and 1044. The pods 1040 and1044, which can each include one or more servers or other computingresources, can perform data processing and other operations used toprovide on-demand services. Communication with the pods can be conductedvia pod switches 1032 and 1036. Components of the on-demand databaseservice environment can communicate with database storage 1056 through adatabase firewall 1048 and a database switch 1052.

As shown in FIGS. 10A and 10B, accessing an on-demand database serviceenvironment can involve communications transmitted among a variety ofdifferent hardware or software components. Further, the on-demanddatabase service environment 1000 is a simplified representation of anactual on-demand database service environment. For example, while onlyone or two devices of each type are shown in FIGS. 10A and 10B, someimplementations of an on-demand database service environment can includeanywhere from one to several devices of each type. Also, the on-demanddatabase service environment need not include each device shown in FIGS.10A and 10B, or can include additional devices not shown in FIGS. 10Aand 10B.

Additionally, it should be appreciated that one or more of the devicesin the on-demand database service environment 1000 can be implemented onthe same physical device or on different hardware. Some devices can beimplemented using hardware or a combination of hardware and software.Thus, terms such as “data processing apparatus,” “machine,” “server” and“device” as used herein are not limited to a single hardware device,rather references to these terms can include any suitable combination ofhardware and software configured to provide the described functionality.

The cloud 1004 is intended to refer to a data network or multiple datanetworks, often including the Internet. Client machines communicablyconnected with the cloud 1004 can communicate with other components ofthe on-demand database service environment 1000 to access servicesprovided by the on-demand database service environment. For example,client machines can access the on-demand database service environment toretrieve, store, edit, or process information. In some implementations,the edge routers 1008 and 1012 route packets between the cloud 1004 andother components of the on-demand database service environment 1000. Forexample, the edge routers 1008 and 1012 can employ the Border GatewayProtocol (BGP). The BGP is the core routing protocol of the Internet.The edge routers 1008 and 1012 can maintain a table of IP networks or‘prefixes’, which designate network reachability among autonomoussystems on the Internet.

In some implementations, the firewall 1016 can protect the innercomponents of the on-demand database service environment 1000 fromInternet traffic. The firewall 1016 can block, permit, or deny access tothe inner components of the on-demand database service environment 1000based upon a set of rules and other criteria. The firewall 1016 can actas one or more of a packet filter, an application gateway, a statefulfilter, a proxy server, or any other type of firewall.

In some implementations, the core switches 1020 and 1024 arehigh-capacity switches that transfer packets within the on-demanddatabase service environment 1000. The core switches 1020 and 1024 canbe configured as network bridges that quickly route data betweendifferent components within the on-demand database service environment.In some implementations, the use of two or more core switches 1020 and1024 can provide redundancy or reduced latency.

In some implementations, the pods 1040 and 1044 perform the core dataprocessing and service functions provided by the on-demand databaseservice environment. Each pod can include various types of hardware orsoftware computing resources. An example of the pod architecture isdiscussed in greater detail with reference to FIG. 10B. In someimplementations, communication between the pods 1040 and 1044 isconducted via the pod switches 1032 and 1036. The pod switches 1032 and1036 can facilitate communication between the pods 1040 and 1044 andclient machines communicably connected with the cloud 1004, for examplevia core switches 1020 and 1024. Also, the pod switches 1032 and 1036may facilitate communication between the pods 1040 and 1044 and thedatabase storage 1056. In some implementations, the load balancer 1028can distribute workload between the pods 1040 and 1044. Balancing theon-demand service requests between the pods can assist in improving theuse of resources, increasing throughput, reducing response times, orreducing overhead. The load balancer 1028 may include multilayerswitches to analyze and forward traffic.

In some implementations, access to the database storage 1056 is guardedby a database firewall 1048. The database firewall 1048 can act as acomputer application firewall operating at the database applicationlayer of a protocol stack. The database firewall 1048 can protect thedatabase storage 1056 from application attacks such as structure querylanguage (SQL) injection, database rootkits, and unauthorizedinformation disclosure. In some implementations, the database firewall1048 includes a host using one or more forms of reverse proxy servicesto proxy traffic before passing it to a gateway router. The databasefirewall 1048 can inspect the contents of database traffic and blockcertain content or database requests. The database firewall 1048 canwork on the SQL application level atop the TCP/IP stack, managingapplications' connection to the database or SQL management interfaces aswell as intercepting and enforcing packets traveling to or from adatabase network or application interface.

In some implementations, communication with the database storage 1056 isconducted via the database switch 1052. The multi-tenant databasestorage 1056 can include more than one hardware or software componentsfor handling database queries. Accordingly, the database switch 1052 candirect database queries transmitted by other components of the on-demanddatabase service environment (for example, the pods 1040 and 1044) tothe correct components within the database storage 1056. In someimplementations, the database storage 1056 is an on-demand databasesystem shared by many different organizations as described above withreference to FIG. 8 and FIG. 9.

FIG. 10B shows a system diagram further illustrating examplearchitectural components of an on-demand database service environmentaccording to some implementations. The pod 1044 can be used to renderservices to a user of the on-demand database service environment 1000.In some implementations, each pod includes a variety of servers or othersystems. The pod 1044 includes one or more content batch servers 1064,content search servers 1068, query servers 1082, file force servers1086, access control system (ACS) servers 1080, batch servers 1084, andapp servers 1088. The pod 1044 also can include database instances 1090,quick file systems (QFS) 1092, and indexers 1094. In someimplementations, some or all communication between the servers in thepod 1044 can be transmitted via the switch 1036.

In some implementations, the app servers 1088 include a hardware orsoftware framework dedicated to the execution of procedures (forexample, programs, routines, scripts) for supporting the construction ofapplications provided by the on-demand database service environment 1000via the pod 1044. In some implementations, the hardware or softwareframework of an app server 1088 is configured to execute operations ofthe services described herein, including performance of the blocks ofvarious methods or processes described herein. In some alternativeimplementations, two or more app servers 1088 can be included andcooperate to perform such methods, or one or more other serversdescribed herein can be configured to perform the disclosed methods.

The content batch servers 1064 can handle requests internal to the pod.Some such requests can be long-running or not tied to a particularcustomer. For example, the content batch servers 1064 can handlerequests related to log mining, cleanup work, and maintenance tasks. Thecontent search servers 1068 can provide query and indexer functions. Forexample, the functions provided by the content search servers 1068 canallow users to search through content stored in the on-demand databaseservice environment. The file force servers 1086 can manage requests forinformation stored in the File force storage 1098. The File forcestorage 1098 can store information such as documents, images, and basiclarge objects (BLOBs). By managing requests for information using thefile force servers 1086, the image footprint on the database can bereduced. The query servers 1082 can be used to retrieve information fromone or more file storage systems. For example, the query system 1082 canreceive requests for information from the app servers 1088 and transmitinformation queries to the NFS 1096 located outside the pod.

The pod 1044 can share a database instance 1090 configured as amulti-tenant environment in which different organizations share accessto the same database. Additionally, services rendered by the pod 1044may call upon various hardware or software resources. In someimplementations, the ACS servers 1080 control access to data, hardwareresources, or software resources. In some implementations, the batchservers 1084 process batch jobs, which are used to run tasks atspecified times. For example, the batch servers 1084 can transmitinstructions to other servers, such as the app servers 1088, to triggerthe batch jobs.

In some implementations, the QFS 1092 is an open source file storagesystem available from Sun Microsystems® of Santa Clara, California. TheQFS can serve as a rapid-access file storage system for storing andaccessing information available within the pod 1044. The QFS 1092 cansupport some volume management capabilities, allowing many disks to begrouped together into a file storage system. File storage systemmetadata can be kept on a separate set of disks, which can be useful forstreaming applications where long disk seeks cannot be tolerated. Thus,the QFS system can communicate with one or more content search servers1068 or indexers 1094 to identify, retrieve, move, or update data storedin the network file storage systems 1096 or other storage systems.

In some implementations, one or more query servers 1082 communicate withthe NFS 1096 to retrieve or update information stored outside of the pod1044. The NFS 1096 can allow servers located in the pod 1044 to accessinformation to access files over a network in a manner similar to howlocal storage is accessed. In some implementations, queries from thequery servers 1082 are transmitted to the NFS 1096 via the load balancer1028, which can distribute resource requests over various resourcesavailable in the on-demand database service environment. The NFS 1096also can communicate with the QFS 1092 to update the information storedon the NFS 1096 or to provide information to the QFS 1092 for use byservers located within the pod 1044.

In some implementations, the pod includes one or more database instances1090. The database instance 1090 can transmit information to the QFS1092. When information is transmitted to the QFS, it can be availablefor use by servers within the pod 1044 without using an additionaldatabase call. In some implementations, database information istransmitted to the indexer 1094. Indexer 1094 can provide an index ofinformation available in the database 1090 or QFS 1092. The indexinformation can be provided to file force servers 1086 or the QFS 1092.

FIG. 11 illustrates a diagrammatic representation of a machine in theexemplary form of a computer system 1100 within which a set ofinstructions, for causing the machine to perform any one or more of themethodologies discussed herein, may be executed. The system 1100 may bein the form of a computer system within which a set of instructions, forcausing the machine to perform any one or more of the methodologiesdiscussed herein, may be executed. In alternative embodiments, themachine may be connected (e.g., networked) to other machines in a LAN,an intranet, an extranet, or the Internet. The machine may operate inthe capacity of a server machine in client-server network environment.The machine may be a personal computer (PC), a set-top box (STB), aserver, a network router, switch or bridge, or any machine capable ofexecuting a set of instructions (sequential or otherwise) that specifyactions to be taken by that machine. Further, while only a singlemachine is illustrated, the term “machine” shall also be taken toinclude any collection of machines that individually or jointly executea set (or multiple sets) of instructions to perform any one or more ofthe methodologies discussed herein.

The exemplary computer system 1100 includes a processing device(processor) 1102, a main memory 1104 (e.g., read-only memory (ROM),flash memory, dynamic random access memory (DRAM) such as synchronousDRAM (SDRAM)), a static memory 1106 (e.g., flash memory, static randomaccess memory (SRAM)), and a data storage device 1118, which communicatewith each other via a bus 1130.

Processing device 1102 represents one or more general-purpose processingdevices such as a microprocessor, central processing unit, or the like.More particularly, the processing device 1102 may be a complexinstruction set computing (CISC) microprocessor, reduced instruction setcomputing (RISC) microprocessor, very long instruction word (VLIW)microprocessor, or a processor implementing other instruction sets orprocessors implementing a combination of instruction sets. Theprocessing device 1102 may also be one or more special-purposeprocessing devices such as an application specific integrated circuit(ASIC), a field programmable gate array (FPGA), a digital signalprocessor (DSP), network processor, or the like.

The computer system 1100 may further include a network interface device1108. The computer system 1100 also may include a video display unit1110 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)),an alphanumeric input device 1112 (e.g., a keyboard), a cursor controldevice 1114 (e.g., a mouse), and a signal generation device 1116 (e.g.,a speaker).

The data storage device 1118 may include a computer-readable medium 1128on which is stored one or more sets of instructions 1122 (e.g.,instructions of in-memory buffer service 114) embodying any one or moreof the methodologies or functions described herein. The instructions1122 may also reside, completely or at least partially, within the mainmemory 1104 and/or within processing logic 1126 of the processing device1102 during execution thereof by the computer system 1100, the mainmemory 1104 and the processing device 1102 also constitutingcomputer-readable media. The instructions may further be transmitted orreceived over a network 1120 via the network interface device 1108.

While the computer-readable storage medium 1128 is shown in an exemplaryembodiment to be a single medium, the term “computer-readable storagemedium” should be taken to include a single medium or multiple media(e.g., a centralized or distributed database, and/or associated cachesand servers) that store the one or more sets of instructions. The term“computer-readable storage medium” shall also be taken to include anymedium that is capable of storing, encoding or carrying a set ofinstructions for execution by the machine and that cause the machine toperform any one or more of the methodologies of the present invention.The term “computer-readable storage medium” shall accordingly be takento include, but not be limited to, solid-state memories, optical media,and magnetic media.

The preceding description sets forth numerous specific details such asexamples of specific systems, components, methods, and so forth, inorder to provide a good understanding of several embodiments of thepresent invention. It will be apparent to one skilled in the art,however, that at least some embodiments of the present invention may bepracticed without these specific details. In other instances, well-knowncomponents or methods are not described in detail or are presented insimple block diagram format in order to avoid unnecessarily obscuringthe present invention. Thus, the specific details set forth are merelyexemplary. Particular implementations may vary from these exemplarydetails and still be contemplated to be within the scope of the presentinvention.

In the above description, numerous details are set forth. It will beapparent, however, to one of ordinary skill in the art having thebenefit of this disclosure, that embodiments of the invention may bepracticed without these specific details. In some instances, well-knownstructures and devices are shown in block diagram form, rather than indetail, in order to avoid obscuring the description.

Some portions of the detailed description are presented in terms ofalgorithms and symbolic representations of operations on data bitswithin a computer memory. These algorithmic descriptions andrepresentations are the means used by those skilled in the dataprocessing arts to most effectively convey the substance of their workto others skilled in the art. An algorithm is here, and generally,conceived to be a self-consistent sequence of steps leading to a desiredresult. The steps are those requiring physical manipulations of physicalquantities. Usually, though not necessarily, these quantities take theform of electrical or magnetic signals capable of being stored,transferred, combined, compared, and otherwise manipulated. It hasproven convenient at times, principally for reasons of common usage, torefer to these signals as bits, values, elements, symbols, characters,terms, numbers, or the like.

It should be borne in mind, however, that all of these and similar termsare to be associated with the appropriate physical quantities and aremerely convenient labels applied to these quantities. Unlessspecifically stated otherwise as apparent from the above discussion, itis appreciated that throughout the description, discussions utilizingterms such as “determining”, “identifying”, “adding”, “selecting” or thelike, refer to the actions and processes of a computer system, orsimilar electronic computing device, that manipulates and transformsdata represented as physical (e.g., electronic) quantities within thecomputer system's registers and memories into other data similarlyrepresented as physical quantities within the computer system memoriesor registers or other such information storage, transmission or displaydevices.

Embodiments of the invention also relate to an apparatus for performingthe operations herein. This apparatus may be specially constructed forthe required purposes, or it may comprise a general purpose computerselectively activated or reconfigured by a computer program stored inthe computer. Such a computer program may be stored in a computerreadable storage medium, such as, but not limited to, any type of diskincluding floppy disks, optical disks, CD-ROMs, and magnetic-opticaldisks, read-only memories (ROMs), random access memories (RAMs), EPROMs,EEPROMs, magnetic or optical cards, or any type of media suitable forstoring electronic instructions.

The algorithms and displays presented herein are not inherently relatedto any particular computer or other apparatus. Various general purposesystems may be used with programs in accordance with the teachingsherein, or it may prove convenient to construct a more specializedapparatus to perform the required method steps. The required structurefor a variety of these systems will appear from the description below.In addition, the present invention is not described with reference toany particular programming language. It will be appreciated that avariety of programming languages may be used to implement the teachingsof the invention as described herein.

While at least one exemplary embodiment has been presented in theforegoing detailed description, it should be appreciated that a vastnumber of variations exist. It should also be appreciated that theexemplary embodiment or embodiments described herein are not intended tolimit the scope, applicability, or configuration of the claimed subjectmatter in any way. Rather, the foregoing detailed description willprovide those skilled in the art with a convenient road map forimplementing the described embodiment or embodiments. It should beunderstood that various changes can be made in the function andarrangement of elements without departing from the scope defined by theclaims, which includes known equivalents and foreseeable equivalents atthe time of filing this patent application.

What is claimed is:
 1. A method for controlling which contributions are displayed in an organization activity timeline of an organization, wherein the organization activity timeline is a visual component displayed within a user interface that shows activities involving a particular external contact and one or more users of the organization, the method comprising: adding an identifier to a blacklist; and blocking, based on the identifier, at least one contribution to a new activity that includes the identifier so that the contribution does not appear in the organization activity timeline.
 2. A method according to claim 1, wherein the blacklist is a user-level blacklist and the identifier is associated with the particular external contact and is specified by a user of the organization, and further comprising: removing the identifier from the user-level blacklist; and allowing, after removing, any new activities that include new contributions by the user to appear in the organization activity timeline.
 3. A method according to claim 1, wherein the blacklist is an organization-level blacklist, and wherein the identifier is associated with the particular external contact and is specified by an administrator of the organization, and wherein blocking comprises: blocking any new activity that includes a contribution associated with the particular external contact associated with the identifier included in the organization-level blacklist from appearing in the organization activity timeline, and further comprising: permanently deleting the any new activity that includes a contribution associated with the particular external contact associated with the identifier in the organization-level blacklist.
 4. A method according to claim 1, wherein the blacklist is an organization-level external domain blacklist, and wherein the identifier is an external domain specified by an administrator of the organization, and wherein blocking comprises: blocking any new activity including any contribution having an external domain included in the organization-level external domain blacklist from appearing in the organization activity timeline; and further comprising: permanently deleting any new activity that includes the external domain included in the organization-level external domain blacklist.
 5. A method according to claim 1, wherein the blacklist is an organization-level internal domain blacklist, and wherein the identifier is an internal domain specified by an administrator of the organization, and wherein blocking comprises: blocking any new activity where all contributors belong to an internal domain included in the organization-level internal domain blacklist so that the new activity does not appear in the organization activity timeline; and further comprising: permanently deleting any new activity where all contributors belong to an internal domain included in the organization-level internal domain blacklist.
 6. A method according to claim 1, wherein the organization activity timeline comprises a chronological record of activities each having at least one contributor that is a user from the organization.
 7. A method according to claim 1, wherein each activity within the organization activity timeline comprises: a recording of a communication between one or more users of the organization and a particular external contact, and wherein the communication comprises: an email; a calendar meeting; a phone call; a task; a note; a change to an internal representation of an external person; or an internal representation of a need or change of that need to follow-up with an external person.
 8. A method according to claim 1, wherein the identifier comprises: any identifier associated with the particular external contact that can be used to identify that particular external contact.
 9. A computing system for controlling which contributions are displayed in an organization activity timeline of an organization, the computing system comprising: a distributed database management system (DDMS) configured to store one or more blacklists each including at least one identifier; an organization activity timeline generator configured to generate the organization activity timeline for the organization, wherein the organization activity timeline is a visual component displayed within a user interface that shows activities involving a particular external contact and one or more users of the organization, wherein the organization activity timeline generator comprises: a real-time activity evaluator configured to ingest new activities received from data sources of the user, determine which new activities include an identifier specified by the one or more blacklists, and block at least one contribution to any new activity that is determined to include an identifier specified by the one or more blacklists so that the contribution does not appear in the organization activity timeline.
 10. A computing system according to claim 9, wherein one of the blacklists is a user-level blacklist that includes an identifier that is associated with the particular external contact and that is specified by a user of the organization, and wherein the real-time activity evaluator is further configured to: allow, after removing the identifier from the user-level blacklist, any new activities that include new contributions by the user to appear in the organization activity timeline.
 11. A computing system according to claim 9, wherein one of the blacklists is an organization-level blacklist that includes an identifier that is associated with the particular external contact and that is specified by an administrator of the organization, and wherein the real-time activity evaluator is further configured to: block any new activity, that includes a contribution associated with the particular external contact, from appearing in the organization activity timeline, and permanently delete any new activity that is blocked.
 12. A computing system according to claim 9, wherein one of the blacklists is an organization-level external domain blacklist that includes an identifier for an external domain that is specified by an administrator of the organization, and wherein the real-time activity evaluator is further configured to: block any new activity, that includes any contribution associated with the external domain included in the organization-level external domain blacklist, from appearing in the organization activity timeline; and permanently delete any new activity that is blocked.
 13. A computing system according to claim 9, wherein one of the blacklists is an organization-level internal domain blacklist that includes an identifier for an internal domain that is specified by an administrator of the organization, and wherein the real-time activity evaluator is further configured to: block any new activity where all contributors belong to the internal domain included in the organization-level internal domain blacklist so that those new activities do not appear in the organization activity timeline; and permanently deleting any new activity that is blocked.
 14. A computing system according to claim 9, wherein the organization activity timeline comprises a chronological record of activities each having at least one contributor that is a user from the organization.
 15. A computing system according to claim 9, wherein each activity within organization activity timeline comprises: a recording of a communication between one or more users of the organization and a particular external contact, and wherein the communication comprises: an email; a calendar meeting; a phone call; a task; a note; a change to an internal representation of an external person; or an internal representation of a need or change of that need to follow-up with an external person.
 16. A computing system comprising a processor and a memory, wherein the memory comprises computer-executable instructions that are capable of execution by the processor, and that when executed by the processor, cause the computing system to: process new activities to determine whether each new activity includes an identifier from a blacklist; and block at least one contribution to each new activity that includes the identifier so that the contribution does not appear in an organization activity timeline of an organization, wherein the organization activity timeline is displayed within a user interface to show activities involving a particular external contact and one or more users of the organization.
 17. A computing system according to claim 16, wherein the blacklist is a user-level blacklist that includes an identifier that is associated with the particular external contact and that is specified by a user of the organization, and wherein the real-time activity evaluator is further configured to: allow, after removing the identifier from the user-level blacklist, any new activities that include new contributions by the user to appear in the organization activity timeline.
 18. A computing system according to claim 16, wherein the blacklist is an organization-level blacklist that includes an identifier that is associated with the particular external contact and that is specified by an administrator of the organization, and wherein the real-time activity evaluator is further configured to: block any new activity, that includes a contribution associated with the particular external contact, from appearing in the organization activity timeline, and permanently delete any new activity that is blocked.
 19. A computing system according to claim 16, wherein the blacklist is an organization-level external domain blacklist that includes an identifier for an external domain that is specified by an administrator of the organization, and wherein the real-time activity evaluator is further configured to: block any new activity, that includes any contribution associated with the external domain included in the organization-level external domain blacklist, from appearing in the organization activity timeline; and permanently delete any new activity that is blocked.
 20. A computing system according to claim 16, wherein the blacklist is an organization-level internal domain blacklist that includes an identifier for an internal domain that is specified by an administrator of the organization, and wherein the real-time activity evaluator is further configured to: block any new activity where all contributors belong to the internal domain included in the organization-level internal domain blacklist so that those new activities do not appear in the organization activity timeline; and permanently deleting any new activity that is blocked. 